Subject: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

From: Thomas Clausen <[email-masked]>
Date: Wed, 20 Apr 2016 11:54:34 +0200

Lotte, all,

> On 19 Mar 2016, at 12:34, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hi Thomas,
> thank you for reviewing AODVv2 yet again :) Some answers below:
> 
>> Am 17.03.2016 um 17:00 schrieb [email-masked]:
>> 
>> 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.
> 
> That wold be great.

I am finding a bit of time here and there when there are holes in the agenda, and am (as you likely have noticed) backtracking through emails when I get a chance. Apologies, I hope that I will get to these emails this, or next week, but day-job eats in to the available time ;(

>> 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.
> 
> That’s what we’ve been trying to say all along! I’m really glad we’re having this conversation.

Then, let us have it -- it's a central point to get right.

>> 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.
> 
> I agree on the usefulness, which is why we were puzzled when we were told we weren’t allowed to use those fields (or, rather, that we were using them wrong, but that the right way to use them doesn’t work for AODvv2). I believe Vicky has written about this in more detail in previous discussions, and we were/are looking forward to reading your answers...

So, the source generates a message, the message is forwarded through the network, with each intermediate router decrementing the hop limit and incrementing the hop count.

As stated in the 5444-Usage document, when forwarding a message, the hop-limit/hop-count are modified, the rest of the message SHOULD not be. 

That is specifically, one thing where I kinda would like 5444-usage to go further is "the message structure MUST in all conditions preserved when forwarding" - but still say "and it is RECOMMENDED that the value field of TLVs are also not modified".

What this buys is several things, in the context of this protocol:

	o	hop-limit/hop-count could be useful for the usual 
		purposes (ensuring that messages do not live forever, 
		scope-limited flooding, ...)

	o	if the accumulated path metric is stored in a TLV value field, that 
		value field can (with suitable disclaimer to call out "we know it is
		RECOMMENDED to not do this, but here's why we are OK in doing
		it anyways") be modified when forwarding the message, and

	o	as that path metric field is in a message whose structure does not
		change, it will be "at the same place in the byte-stream" at each hop,
		which
	
	o	allows useful things such as deriving from RFC7182 a form of
		"when calculating the ICV, zero out that field in the message ' when
		  validating an ICV, also zero out that field" -- which goes one step
		  further (when coupled with a time stamp) than simple transitive trust, 
		  but also

	o	allows even more fancy and useful (albeit experimental) things such
		as aggregate signatures to work correctly.

Furthermore.....

>> 		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.
> 
> Exactly; we’d really like to avoid this as well.
> 

... It avoids the above, and....

>> 
>> 		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”.
> 
> AODVv2’s duplicated detection hopefully should take care of that. Iirc, We interpreted your earlier E-Mails to (implicitly) mean that you think we should rely on that, since you said we can’t use the hop-limit/hop-count fields.
> 

....if done (proper forwarding with preservation of the structure, rather than regeneration which opens up the "this is a new message with potentially new structure" can of worms) as I describe, also addresses the above.

With respect to what I said earlier when I said "can't use hop-limit/hop-count fields"....when you regenerate, you absolutely, definitely, can't.

When you "regenerate" a message, that means "you construct a brand new message" which may shuffle addresses inside address blocks, or between address blocks, shuffle TLVs differently than they were originally, even use TLVs of different structure (e.g., single-value TLVs instead of multi-value TLVs). 

This means that some assumptions (such as when producing an ICV for the message, which depends on the byte order) don't hold. Well, they may not hold, so that means we can't assume that they do. Which means that the originator of a message cannot generate an ICV that can be correctly interpreted (which is what my next section in my original mail was about).

Which means, in conclusion,  that the information in the message profoundly change -- and therefore these hop-count/hop-limit values do not even apply to "the information". 

However if proper forwarding with preservation of the structure, rather than regeneration which opens up the "this is a new message with potentially new structure" can of worms, as I (& Ulrich & others) have suggested, is taken to heart, it also addresses the issue below regarding end-to-end authentication (which, while still hard, is possible).

A couple of more comments below

>> 
>> 	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.
> 
> The possible benefit is that we need to accumulate & transport metric values somehow, and we can’t do that without regenerating at least parts of the message.
> If we’re missing a solution here, please share it with us.
> 

Done in the above.

>> 
>> Security Considerations
> 
> Just for context’s sake, did you review the security considerations in draft-ietf-manet-aodvv2-13 or the ones proposed in the thread „AODVv2: Security considerations update“?

I did. It still is a far cry from passing the bar. I've posted on why in the past, and some more in this mail (which also contains some suggestions).

I would suggest that settling the rearchitecturing to do forwarding, as I describe in the above, should be done, which would ease the security considerations issue considerably (and which would be necessary even if ignoring the security considerations, IMO, for this doc to go anywhere). 

With a new version covering that, the authors (I wanted to write "you", but decided to be inclusive) could you go look at the different security emails and perhaps start a separate thread on that, towards a resolution?

Best,

Thomas

> 
>> 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)
>> 
>> 		o	When a RREQ, RREP message is transmitted  (by the source, or forwarded by an intermediary)
>> 			in an RFC5444 packet, an ICV Packet TLV is added to the packet, which is calculated <this way> …
>> 
>> 		o	When an RFC5444 packet is received, validate the ICV Packet TLV <this way> and if the ICV doesn’t validate,
>> 			discard the contained messages.
>> 
>> 		o	When receiving a RREQ/RREP (either as destination, or as an intermediary), validate the ICV Message TLV 
>> 			<this way> and if the ICV doesn’t validate, discard the message, do not process, do not forward.
>> 
>> This is a different (and more flexible?) model than “just” transitive trust and “just” end-to-end trust discussed previously, and is enabled by the “forwarding” bit described previously.
>> 
>> Metrics
>> I have asked this numerous times, but have not gotten any answer so I am escalating this again. Why is this document having a normative reference to RFC6551?
>> 
>>    [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
>>               and D. Barthel, "Routing Metrics Used for Path Calculation
>>               in Low-Power and Lossy Networks", RFC 6551, DOI 10.17487/
>>               RFC6551, March 2012,
>>               <http://www.rfc-editor.org/info/rfc6551>.
>> 
>> 
>> Unless I am mistaken, this is not the ROLL WG. And the abstract to RFC6551 explicitly reads:
>> 
>>    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.  
>> Which explicitly is disclaiming that these metrics are not applicable in ad hoc networks — and, I am wondering, what has changed since the publication of RFC6551 to suddenly make these applicable?
>> 
>>  I am also wondering if looking at (and, perhaps, using?) the same metric type TLV type as in OLSRv2 is not a possibility?
>> 
>> Either way, referencing RFC6551 here is wrong.
>> 
>> RFC6621 (SMF) usage
>> As late as earlier this month, RFC6621 reared its head again on the mailing list. I understand that the authors are set on using flooding reduction as part of RREQ distribution. If that is the case, then this protocol MUST specify that flooding reduction. 
>> 
>> Saying “Use RFC6621” won’t work, for reasons Chris point out in an email earlier to the list:
>>> The network does not and fundamentally cannot offer multicast suppression to AODVv2. This isn't a hard concept, but seems to keep having to be said. AODVv2 messages are carried in 5444 packets, and those only travel one hop. That doesn't allow for suppression. Furthermore AODVv2 is creating new messages each hop. That needs AODVv2 specific handling.
>> 
>> 
>> And quoting an email from myself:
>>> If protocol X relies on using a flooding operation, then it certainly is protocol X's responsibility to  specify the flooding operation (or, at least, the requirements to the flooding operation ) for correct functioning of protocol X.
>> 
>> I’ve previously pointed out that RFC6621 requires some degree of configuration (can’t just, for example, pick two different relay set selection algorithms, as that may produce a disconnected flooding domain).
>> 
>> In other words, what the authors propose in https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 is insufficient.
>> 
>> Multiple interfaces configured with the same address(es) - & RFC6621
>> I think that it has been established that the ability to use the same address on multiple interfaces is a requirement. It’s not clear to me that a single way of doing so has been proposed, nor that the “operating conditions” are called out (for example, will it work  if router A and router B both have two interfaces, and that all 4 interfaces use the same IP address?)
>> 
>> This is not entirely unrelated to flooding reduction and RFC6621. One of the complexities is to get that just right: OLSRv2 - for example - calculates Flooding-MPRs per interface, and RFC6130 is careful in how it detects bidirectionality of links. 
>> 
>> I have not worked out all the details of how this impacts this protocol — but, it requires attention. Especially when wanting to be able to say “…use RFC6621”, then the interface configuration constraints when faced with multiple interfaces must be worked out.
>> 
>> Prefixes & Gateways
>> A question to my mind, and I am not sure I know how to answer that from reading the draft since it is not discussed in section 9 (at least), is: “What happens if I send a RREQ to a prefix” (i.e., a /<128 in IPv6)?
>> 
>> 	o	If the whole prefix is part of the attached network set of a single router, 
>> 		then I expect to get a single RREP back, is that the case?
>> 
>> 	o	If "half the prefix"  is part of the attached network set of a single router, 
>> 		and the other half is part of the attached network set of another  single router, 
>> 		then I expect two RREPs, is that the case?
>> 
>> 	o	More generally, will I get a tree build through the network here?
> 
> AODVv2 currently doesn’t support RREQs for prefixes. I’ve already added „If RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD equal address length.“ to RteMsg.TargPrefixLen in section 4.6. Multicast Route Message Table in response to Justin’s comments, but I’ll go through the draft again and see where we need to state this more clearly.
> 
> Best regards,
> Lotte Steenbrink
> 
>> 
>> Section 9 (or, the whole spec) is also not explicit enough about multiple  "default gateways" — i.e., the external network being “the rest of the Internet”, and there being multiple gateways to the Internet. I understand how the RREQ gets to the gateway, and how the gateway determines if it should respond (the destination is not part of “the MANET prefix, with which it is configured”).
>> 
>> But, if A is close to GW1, and B is close to GW2, but A and B being far far apart (according to the metric used) within the MANET, then it would be preferential for the route from A to B to go via GW1-“the-Internet”-GW2? 
>> 
>> Is this a supported configuration? 
>> 	o	If yes, how is it (seq# wise, I would expect some complications) handled? 
>> 	o	If not, where is it stated that this configuration is not possible with this protocol?
>> 
>> 
>> The applicability statement says:
>> 
>>    AODVv2 is designed for stub or disconnected mobile ad hoc networks,
>>    i.e., non-transit networks or those not connected to the internet.
>>    AODVv2 can, however, be configured to perform gateway functions when
>>    attached to external networks, as discussed in Section 9.
>> 
>> I believe that the scenario I describe is indeed a stub network (and not a transit network)?
>> 
>> — — — 
>> 
>> As I indicated, these are the big-picture issues that I have gotten around to thinking about enough to write up. I’m not through working through the document, but those were the ones that came to mind, and which seem imperative to resolve.
>> 
>> Best,
>> 
>> Thomas
>> 
>> 
>> 
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 20 Apr 2016 10:30:29 +0000

Can I just say it’s quite hard to work out who is saying what in these exchanges. I’m having to guess some on the basis of “that sounds like Thomas” or “that sounds like Lotte”.

What I’m not clear on is what conclusion, if any, you’ve drawn on hop count/limit.

As I see it, if the protocol receives a message then sends a message similar but not identical to that out, that can be reviewed as creating a new message. It is a new message as far as 7182 is concerned.

But the protocol could impose some restrictions. For example “the only thing allowed to be changed is this field in this TLV”. Which it would therefore be a good idea for the creator of the message to include, even if it thus needed to include a link metric of zero. (Which is a design point - you might need to allow that in metric specification.) But you would need to state that. That enables some future designs - not 7182, possibly an extension to 7182, possibly something new. There is a problem that this idea would be putting in a need to understand specific TLVs, which is undesirable. I have some ideas there, such as using the protocol-specific space, but this isn’t a five minute job, and needs to be got right. While now is not the time to define this, some decisions could really impact on future designs. For example putting anything wanting to be mutable stuck in the middle of all the other TLVs would be constraining. Making all intended to be mutable by this protocol TLVs in the protocol specific space is probably the least bad idea, as that could be generalised (either making that space not covered by this hypothetical 7182 variant, or splitting it).

That leaves hop count/limit. Technically you wouldn’t increment/decrement, as it’s a new message. But you can send any hop limit on any new message, so that could be one less than the one you received. Hop count is a bit more arguable. I’m not sure how clearly its meaning is indicated, whether it is a “real” hop count of this message. But if you needed to I wouldn’t be too strongly against doing what looks like incrementing that, as long as carefully explained. (A key question is if you use 5497 TLVs. In that case I think - combined with the “only change one thing above” that you need to appear to increment hop limit, i.e. create a new message with a non-zero hop count.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:[email-masked]] On Behalf Of Thomas Clausen
Sent: 20 April 2016 10:55
To: Lotte Steenbrink
Cc: Mobile Ad Hoc Networks mailing list
Subject: [manet] On Forwarding-and-regeneration (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>.
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Lotte, all,

On 19 Mar 2016, at 12:34, Lotte Steenbrink <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas,
thank you for reviewing AODVv2 yet again :) Some answers below:

Am 17.03.2016 um 17:00 schrieb [email-masked]<mailto:[email-masked]>:

Dear all,

That wold be great.

Furthermore.....

Done in the above.

Security Considerations

Best,

Thomas

Metrics

              in Low-Power and Lossy Networks", RFC 6551<https://tools.ietf.org/html/rfc6551>, DOI 10.17487/

              RFC6551<https://tools.ietf.org/html/rfc6551>, March 2012,

RFC6621 (SMF) usage

Prefixes & Gateways

AODVv2 currently doesn’t support RREQs for prefixes. I’ve already added „If RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD equal address length.“ to RteMsg.TargPrefixLen in section 4.6<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-4.6>. Multicast Route Message Table in response to Justin’s comments, but I’ll go through the draft again and see where we need to state this more clearly.

Best regards,
Lotte Steenbrink

   attached to external networks, as discussed in Section 9<https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-9>.

— — —

Best,

Thomas

_______________________________________________
manet mailing list
[email-masked]<mailto:[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: [email-masked]
Date: Wed, 20 Apr 2016 17:53:09 +0200

Justin, all,

Apologies for the delayed response to this. Day-job, and all that, I know you know what I’m talking about…

> On Mar 23, 2016, at 13:59, Justin Dean <[email-masked]> wrote:
> 
> On Tue, Mar 22, 2016 at 5:04 PM, Thomas Heide Clausen <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On 22 Mar 2016, at 21:51, Justin Dean <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> I think you're misunderstanding my point. It's my opinion that it's past time to come up with some elegant and complex solution to fix this issue. Simple and safe solutions should be preferred as we'd likely miss something. This is regardless of when the outstanding problem was first raised.
>> 
> 
> My point is that it is an issue that must be addressed: the requirements that multiple interfaces can be sharing the same address is old, I have raised it multiple times over the years. OLSRv2 was built to support it. Henning reported an additional use case.
> 
> The WG chair suggesting to disallow it, or to "bridge it", is *not* solving the issue raised. It is the WG chair ignoring legitimate requirements from the WG, which does not strike me as aligned with proper process.
> 
> The WG chair saying "it is past time to solve" a long raised (and ignored) issue does not strike me as being aligned with proper process either.
> 
> Thomas
> 
> Since you seem quite passionate about this issue let's work on fixing it then. 

Thanks, appreciate it.

> I looked back over NHDP to see how we "solved" this issue (vaguely remembering something about limiting the address assignment when two interfaces on a node could reach the same medium but was unable to find that).

I have not looked it up, but the trick is indeed in that area, plus what you write below also.

Part of the motivation is, that if you do not do that, you may (potentially) break MPR flooding (remember, the race condition diagrams …?), so restrictions like that are in order.

> It works because we tag neighboring addresses with either link or neighbor status based on the incoming interface on which we received hello messages.
> It seems to me that if AODVv2 limited RREP messages to the interface on which the RREQ came in on (multicast or otherwise) that this would fix the issue.

Did anyone work through that/if this approach would work? I haven’t actually constructed a proof, but for a network without reduced relay set flooding optimizations, I’ve not been able to find a counter-example which would easily break it [as described above], which is at least a good thing ;)

Now, as to how to implement it….

> To do this the Neighbor Table (section 6.3) would have to be updated to include the local interface on which this neighbor is associated with. 
> When attempting to check bidirectionality messages would only be sent out on the listed interface.  This would be similar to the link table in NHDP and link tlv types.

Would that not entail an additional restriction required, such that the neighbor (as identified by an address) is reachable only over one, but not the other, interface? I.e., if the same address is used for two interfaces on a router, then those two must unequivocally be on different channels?

It seems that this avenue would be well worth developing, actually.

Best,

Thomas 

> Justin

---

From: [email-masked]
Date: Wed, 20 Apr 2016 18:05:53 +0200

Chris, all,

> On Apr 20, 2016, at 12:30, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 

I think that your MUA is slightly broken, then, but when I have doubts I hit the archives, which correctly shows who says what — here’s the archive for the message in question:

	http://mailarchive.ietf.org/arch/msg/manet/MCxWf0tLc9Q7Ix_XW_0lAPyHIdc <https://mailarchive.ietf.org/arch/msg/manet/MCxWf0tLc9Q7Ix_XW_0lAPyHIdc>

> As I see it, if the protocol receives a message then sends a message similar but not identical to that out, that can be reviewed as creating a new message. It is a new message as far as 7182 is con…

Hence why I wrote (or, I think I wrote) 7182-derived TLV.

>  
> But the protocol could impose some restrictions. For example “the only thing allowed to be changed is this field in this TLV”. Which it would therefore be a good idea for the creator of the message to include, even if it thus needed to include a link metric of zero. (Which is a design point - you might need to allow that in metric specification.) But you would need to state that. That enables some future designs - not 7182, possibly an extension to 7182, possibly something new.

YES, that’s my point.

> There is a problem that this idea would be putting in a need to understand specific TLVs, which is undesirable. I have some ideas there, such as using the protocol-specific space, but this isn’t a five minute job, and needs to be got right. While now is not the time to define this, some decisions could really impact on future designs. For example putting anything wanting to be mutable stuck in the middle of all the other TLVs would be constraining. Making all intended to be mutable by this protocol TLVs in the protocol specific space is probably the least bad idea, as that could be generalised (either making that space not covered by this hypothetical 7182 variant, or splitting it).

My position on that would be “never change the structure of the message in transit” and “never change the length on a TLV in transit”, and you’d have done a fairly good job of making it possible to do *something* clever for ICVs: the mutating field, which would be in a fixed position in the byte stream, you could zero that out, or do something else. 7182 does not do that. But something else might.

Not having that constraint means that “something else” would be impossible, would impede on extensibility.

>  
> That leaves hop count/limit. Technically you wouldn’t increment/decrement, as it’s a new message. But you can send any hop limit on any new message, so that could be one less than the one you received. Hop count is a bit more arguable. I’m not sure how clearly its meaning is indicated, whether it is a “real” hop count of this message. But if you needed to I wouldn’t be too strongly against doing what looks like incrementing that, as long as carefully explained.

Yes, I agree that that can be arguable.

Again, here my position is: if you change the slightest in the *structure* of the message, then a hop-count increment would be invalid (illegal? ;) ) 

Which is to say: regeneration => don’t use hop-count/hop-limit (in my opinion).

> (A key question is if you use 5497 TLVs. In that case I think - combined with the “only change one thing above” that you need to appear to increment hop limit, i.e. create a new message with a non-zero hop count.

Indeed, good catch. This document does, indeed, cite RFC5497 normatively. I’d not seen that interaction, but you are right it has to be matched up. I’ve not checked that/if it is.

Best,

Thomas

> T:  +44 (0)1245 242194  |  E: [email-masked] <mailto:[email-masked]>
> 
> www.baesystems.com/ai <http://www.baesystems.com/ai>
> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Thomas Clausen
> 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 ***
> On 19 Mar 2016, at 12:34, Lotte Steenbrink <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Thomas,
> Am 17.03.2016 um 17:00 schrieb [email-masked] <mailto:[email-masked]>:
>  
> Dear all,
>  
>                         The proposal from https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 <https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00>
>                         Aggregate signature algorithms ( https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf <https://crypto.stanford.edu/~dabo/papers/aggsurvey.pdf>)
>                         updating to  https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00 <https://tools.ietf.org/html/draft-perkins-manet-aodv-e2esec-00>)
>  
>    [RFC6551 <>]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
>               in Low-Power and Lossy Networks", RFC 6551 <https://tools.ietf.org/html/rfc6551>, DOI 10.17487/
>               RFC6551 <https://tools.ietf.org/html/rfc6551>, March 2012,
>               <http://www.rfc-editor.org/info/rfc6551 <http://www.rfc-editor.org/info/rfc6551>>.
>  
>  
> Which explicitly is disclaiming that these metrics are not applicable in ad hoc networks— and, I am wondering, what has changed since the publication of RFC6551 to suddenly make these applicable?
>  
> In other words, what the authors propose in https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00 <https://tools.ietf.org/html/draft-perkins-manet-using-rfc6621-00> is insufficient.
>  
> AODVv2 currently doesn’t support RREQs for prefixes. I’ve already added „If RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD equal address length.“ to RteMsg.TargPrefixLen in section  <>4.6 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-4.6>. Multicast Route Message Table in response to Justin’s comments, but I’ll go through the draft again and see where we need to state this more clearly.
>  
> Best regards,
> Lotte Steenbrink
> 
> 
>  
>    attached to external networks, as discussed in Section 9 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-9>.
>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/manet <https://www.ietf.org/mailman/listinfo/manet>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 21 Apr 2016 08:59:34 +0000

I’m reading this in Outlook. (Or rather in a mixture of Outlook and on my phone. But this one in Outlook.) And in Outlook, quite broken with no information on who said what.

From: [email-masked] [mailto:[email-masked]]
Sent: 20 April 2016 17:06
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***

On Apr 20, 2016, at 12:30, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

            http://mailarchive.ietf.org/arch/msg/manet/MCxWf0tLc9Q7Ix_XW_0lAPyHIdc<https://mailarchive.ietf.org/arch/msg/manet/MCxWf0tLc9Q7Ix_XW_0lAPyHIdc>

YES, that’s my point.

Best,

Thomas

*** WARNING ***

Lotte, all,

Dear all,

That wold be great.

Furthermore.....

Done in the above.

Security Considerations

Best,

Thomas

Metrics

RFC6621 (SMF) usage

Prefixes & Gateways

Best regards,
Lotte Steenbrink

— — —

Best,

Thomas

---

From: Lotte Steenbrink <[email-masked]>
Date: Fri, 22 Apr 2016 11:05:01 +0200

Hi Thomas,

> Am 20.04.2016 um 11:54 schrieb Thomas Clausen <[email-masked]>:
> 
> Lotte, all,
> 
> 		scope-limited flooding, …)

Exactly.

> 		it anyways") be modified when forwarding the message, and

Can it?! Iirc, the reason why we adopted the “regeneration” language in the first place is that we’ve been told that whenever one bit in the message (apart from its header) is changed, the entire thing has to be regenerated. I’m starting to get the feeling we’ve just been misunderstanding each other for more than a year. :( Anyway, it seems like we’re getting close now, so yay.

> 		  further (when coupled with a time stamp) than simple transitive trust, 

Well if that’d be possible, that’d solve a *huge* lump of problems. I’m guessing the remaining caveat would be that an attacker (or a buggy router) might still tamper with the metric value without being detected, which could divert routes (i.e. routes being established when they shouldn’t and dropped when they shouldn’t). Obviously this needs to be pointed out in the security considerations, but it’d be a massive improvement. 
Do the other 5444 experts agree that we can do this? If yes, I’ll come up with some suggestions for suitable text tonight and run it by the list to see if it makes sense.

> Which means, in conclusion,  that the information in the message profoundly change -- and therefore these hop-count/hop-limit values do not even apply to "the information“. 

Okay, that makes sense. I thought we might have some wiggle room, saying “yes, we're constructing a new message, but that just happens to have a hop count that’s lastMessage.hopcount -1”. But if your above outline is legal (which, as I said, we just thought we couldn’t do what you’ve described, and I’m pretty sure I’ve asked this list and Henning all kinds of questions revolving around this topic last spring), we won’t need hacks like those anyway, so I won’t entertain them any further. ;)

> I did. It still is a far cry from passing the bar. I've posted on why in the past, and some more in this mail (which also contains some suggestions).

Just as a comment, the new Security Considerations and their reorganization were actually based on BCP72 (as suggested by Chris, I think?)– if you have any concrete pointers where I missed something, I’d be glad to hear about them.

> With a new version covering that, the authors (I wanted to write "you", but decided to be inclusive) could you go look at the different security emails and perhaps start a separate thread on that,…

Sounds like a good plan, I’ll do that tonight as well (unless somebody beats me to it :D).

Best regards,
Lotte

>> AODVv2 currently doesn’t support RREQs for prefixes. I’ve already added „If RteMsg is a RREQ, RteMsg.TargPrefixLen SHOULD equal address length.“ to RteMsg.TargPrefixLen in section 4.6 <https://tools.ietf.org/html/draft-ietf-manet-aodvv2-13#section-4.6>. Multicast Route Message Table in response to Justin’s comments, but I’ll go through the draft again and see where we need to state this more clearly.
>> 
>> Best regards,
>> Lotte Steenbrink
>> 
>>>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 22 Apr 2016 11:08:27 +0200

On Fri, Apr 22, 2016 at 11:05 AM, Lotte Steenbrink
<[email-masked]> wrote:
> Hi Thomas,
> Can it?! Iirc, the reason why we adopted the “regeneration” language in the
> first place is that we’ve been told that whenever one bit in the message
> (apart from its header) is changed, the entire thing has to be regenerated.
> I’m starting to get the feeling we’ve just been misunderstanding each other
> for more than a year. :( Anyway, it seems like we’re getting close now, so
> yay.

"Modifying" the binary message instead of parsing and generating a new
one will be difficult as soon someone writes an extension to AODVv2
that adds more TLVs to the message.

Henning Rogge

---

From: Lotte Steenbrink <[email-masked]>
Date: Fri, 22 Apr 2016 11:28:17 +0200

Hi Henning,

> Am 22.04.2016 um 11:08 schrieb Henning Rogge <[email-masked]>:
> 

D’oh, right. Yeah, if I remember it correctly, that’s what you explained to me when I got confused about the topic last spring… But– even if a message contains TLVs that the AODVv2 implementation handling it doesn’t understand, it will still be able to recognize the Metric TLV, right? Isn’t that the nifty thing about RFC5444? So, while we really shouldn’t write “before calculating the ICV, set the n-th 4 octets to 0”, we might say “identify the octets that make up the metric value and set those to 0”?

Best regards,
Lotte

---

From: Henning Rogge <[email-masked]>
Date: Fri, 22 Apr 2016 11:31:17 +0200

> D’oh, right. Yeah, if I remember it correctly, that’s what you explained to me when I got confused about the topic last spring… But– even if a message contains TLVs that the AODVv2 implementation h…

Of course... you can build a "binary modifier" for RFC5444...

in fact I have done something like this on the way to implement
signatures (RFC7182) because you need the message layout before you
can calculate the hash.

And I can tell you it can be a pain in the *** for a generic
parser/generator system. It is worse for signatures (you need to
add/remove TLVs), but it is still not trivial for your usecase.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 22 Apr 2016 09:57:02 +0000

Just be careful to note that this concept is as currently being discussed (a) specific to AODVv2, and (b) not an application of 7182, which has no knowledge of special TLVs.

This is something we'd want to get right, and need to get right if in any space not specific to ADODVv2, because getting it wrong produces future problems.

I can see some possible approaches, none is ideal and we're rather out of time to specify. But this is experimental, so I think we might be able to indicate the shape of the solution without specifying it, which would be a different RFC, under a bit less time pressure. (Extensions to existing protocols like 7182 would naturally be in scope rechartered I think.)

To indicate the range that's open, here are two possible ideas, one of which has an impact now, so needs to be agreed. Note that I'm not suggesting (in fact quite the opposite) defining an extension to 7182 here, rather enabling such an extension, if written, to "do the right thing".
- We have an extension to 7182 that says "zero out all value octets in protocol specific TLVs. That requires now putting the AODVv2 metric TLV in that space.
- We have an extension to 7182 that adds extra material to the value field that indicates (TBD how, by position with sanity check that this is TLV value perhaps?) which octets are to be zeroed out before the ICV is calculated.

We do not have the time to specify this in an acceptable manner within two weeks though. But the security consideration section could say something along the lines of "this enables the use of an ICV defined to zero out these octets".

T:  +44 (0)1245 242194  |  E: [email-masked]

www.baesystems.com/ai

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Lotte Steenbrink
Sent: 22 April 2016 10:28
To: Henning Rogge
Cc: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On Forwarding-and-regeneration (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 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.
--------------------------------------------------------

*** WARNING ***

Hi Henning,

>> Can it?! Iirc, the reason why we adopted the “regeneration” language 
>> in the first place is that we’ve been told that whenever one bit in 
>> the message (apart from its header) is changed, the entire thing has to be regenerated.
>> I’m starting to get the feeling we’ve just been misunderstanding each 
>> other for more than a year. :( Anyway, it seems like we’re getting 
>> close now, so yay.
> 

Best regards,
Lotte

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 22 Apr 2016 14:49:25 +0200

> On 22 avr. 2016, at 11:57, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 

It would seem obvious that this "special TLV" would be specified without a reserved TLV type from the IANA registries - and that in the experiment enabled by an experimental RFC, we would want to use (TLV, message) types from the Experimental type space from these registries. This precisely because this is something which, as Chris suggests, "getting wrong produces future problems". 

Thomas
(Running between meetings)

---

From: Lotte Steenbrink <[email-masked]>
Date: Fri, 22 Apr 2016 14:58:47 +0200

Hello Christopher,

> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <[email-masked]>:
> 

Makes sense.

> - We have an extension to 7182 that says "zero out all value octets in protocol specific TLVs. That requires now putting the AODVv2 metric TLV in that space.

Just to make sure that I understood you correctly– “that space” meaning making the AODVv2 metric TLV protocol specific? (By “the aodvv2 metric tlv” I’m referring to the generic TLV we’ve been talking about on this list earlier this week).

> - We have an extension to 7182 that adds extra material to the value field that indicates (TBD how, by position with sanity check that this is TLV value perhaps?) which octets are to be zeroed out…

The way I understand that approach, it wouldn’t warrant any action from AODVv2 besides saying “if you calculate the ICV, set the Metric value to zero” (leaving the nitty gritty of how this would be done in detail to future work)… Is that correct?

> 
> We do not have the time to specify this in an acceptable manner within two weeks though. But the security consideration section could say something along the lines of "this enables the use of an ICV defined to zero out these octets“.

Okay. :)

Best regards,
Lotte

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 22 Apr 2016 13:05:33 +0000

Once you're entirely in AODV2's own space, and AODVv2 is experimental (working assumption for this discussion) you have more liberty.

Then you could try specifying it. But with a very good chance of producing something you later decide you should have done differently.

I honestly don't know which would go down better (or less badly) - "here's a mechanism we haven't really thought through in detail, but at least we've defined one", or "we know the sort of thing we want, and we'll describe it, but rather than produce something not quite right, we'll not go further".

-----Original Message-----
From: Lotte Steenbrink [mailto:[email-masked]] 
Sent: 22 April 2016 13:59
To: Mobile Ad Hoc Networks mailing list
Cc: Henning Rogge; Dearlove, Christopher (UK)
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

Hello Christopher,

Makes sense.

> I can see some possible approaches, none is ideal and we're rather out 
> of time to specify. But this is experimental, so I think we might be 
> able to indicate the shape of the solution without specifying it, 
> which would be a different RFC, under a bit less time pressure. 
> (Extensions to existing protocols like 7182 would naturally be in 
> scope rechartered I think.)
> 

Okay. :)

Best regards,
Lotte

> BAE Systems Applied Intelligence Limited Registered in England & Wales 
> No: 01337451 Registered Office: Surrey Research Park, Guildford, 
> Surrey, GU2 7YP
> 
> Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: 
> draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)
> 
>>> I’m starting to get the feeling we’ve just been misunderstanding 
>>> each other for more than a year. :( Anyway, it seems like we’re 
>>> getting close now, so yay.
>> 
>> "Modifying" the binary message instead of parsing and generating a 
>> new one will be difficult as soon someone writes an extension to 
>> AODVv2 that adds more TLVs to the message.
>> 
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 22 Apr 2016 15:21:28 +0200

> On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <[email-masked]> wrote:
> 

Yep. 

Taken somewhat by surprise both by the sudden "rush" and the experimental maturity level, I am wondering (and haven't thought through) about experimental space vs non-experimental (for message types, and consequently for message type specific TLV types). 

I think that if the AODVv2 experiment specifies the use of Message types from the Experimental message type space without making actual registrations in the IANA registry, AND the use of type specific TLV types, this becomes a non-issue entirely (by design, this is precisely what that experimental space is for)

Whereas, as you point out, the alternative is a "can open - worms everywhere" situation that I think time is too short to solve?

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 22 Apr 2016 13:35:10 +0000

There's rather a contradiction between the concepts of a definition of a protocol, even Experimental, and experimental space, which usually assumes that the user can do what he or she likes in it.

But chewing up messages types (how many, 3?) of which there are relatively few for experimental is long term a problem, although short term not.

TLV space is easier in two regards. It's bigger (though the prime real estate of type extension zero isn't) and can have message type specific TLVs.

So TLVS can actually be invisible, if that option is chosen. For messages something has to give. Least bad option is again one of those we should discuss, but time ...

(To be precise, messages types from 224 are defined in RFC 5444 as " Experimental Use", of which BCP 26 says "Similar to private or local use only, with the  purpose being to facilitate experimentation." The alternative 0-223 space is Expert Review. IANA still thinks the experts are Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)

-----Original Message-----
From: Thomas Heide Clausen [mailto:[email-masked]] 
Sent: 22 April 2016 14:21
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

Yep. 

Thomas

---

From: Justin Dean <[email-masked]>
Date: Fri, 22 Apr 2016 10:35:09 -0400

Speaking as participant.

I kind of like the idea of using the experimental message type space.  We
only have a limited amount of these message types.  The TLV assignments
could just use the message type specific space and there isn't an issue
there.  IANA wouldn't assign a number but I don't see why the document
couldn't specify the experimental numbers it was going to use so other
future near term experiential protocols could do the same and generally
avoid conflict.  If the experiment is successful IANA assignments could be
made.  Functionally no real difference with protections vs long term usage
of limited space.

Justin

On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> There's rather a contradiction between the concepts of a definition of a
> protocol, even Experimental, and experimental space, which usually assumes
> that the user can do what he or she likes in it.
>
> But chewing up messages types (how many, 3?) of which there are relatively
> few for experimental is long term a problem, although short term not.
>
> TLV space is easier in two regards. It's bigger (though the prime real
> estate of type extension zero isn't) and can have message type specific
> TLVs.
>
> So TLVS can actually be invisible, if that option is chosen. For messages
> something has to give. Least bad option is again one of those we should
> discuss, but time ...
>
> (To be precise, messages types from 224 are defined in RFC 5444 as "
> Experimental Use", of which BCP 26 says "Similar to private or local use
> only, with the  purpose being to facilitate experimentation." The
> alternative 0-223 space is Expert Review. IANA still thinks the experts are
> Joe Macker and the recused Stan Ratliff. But that's a soluble nit.)
>
> --
> Christopher Dearlove
> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> > Once you're entirely in AODV2's own space, and AODVv2 is experimental
> (working assumption for this discussion) you have more liberty.
> >
>
> Yep.
>
> Taken somewhat by surprise both by the sudden "rush" and the experimental
> maturity level, I am wondering (and haven't thought through) about
> experimental space vs non-experimental (for message types, and consequently
> for message type specific TLV types).
>
> I think that if the AODVv2 experiment specifies the use of Message types
> from the Experimental message type space without making actual
> registrations in the IANA registry, AND the use of type specific TLV types,
> this becomes a non-issue entirely (by design, this is precisely what that
> experimental space is for)
>
> Whereas, as you point out, the alternative is a "can open - worms
> everywhere" situation that I think time is too short to solve?
>
> Thomas
>
>
> > Then you could try specifying it. But with a very good chance of
> producing something you later decide you should have done differently.
> >
> > I honestly don't know which would go down better (or less badly) -
> "here's a mechanism we haven't really thought through in detail, but at
> least we've defined one", or "we know the sort of thing we want, and we'll
> describe it, but rather than produce something not quite right, we'll not
> go further".
> >
> > --
> > Christopher Dearlove
> > ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> > Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on reporting suspicious email messages.
> >> Just be careful to note that this concept is as currently being
> discussed (a) specific to AODVv2, and (b) not an application of 7182, which
> has no knowledge of special TLVs.
> >>
> >> This is something we'd want to get right, and need to get right if in
> any space not specific to ADODVv2, because getting it wrong produces future
> problems.
> >
> > Makes sense.
> >
> >> To indicate the range that's open, here are two possible ideas, one of
> which has an impact now, so needs to be agreed. Note that I'm not
> suggesting (in fact quite the opposite) defining an extension to 7182 here,
> rather enabling such an extension, if written, to "do the right thing".
> >> - We have an extension to 7182 that says "zero out all value octets in
> protocol specific TLVs. That requires now putting the AODVv2 metric TLV in
> that space.
> >
> > Just to make sure that I understood you correctly– “that space” meaning
> making the AODVv2 metric TLV protocol specific? (By “the aodvv2 metric tlv”
> I’m referring to the generic TLV we’ve been talking about on this list
> earlier this week).
> >
> >> - We have an extension to 7182 that adds extra material to the value
> field that indicates (TBD how, by position with sanity check that this is
> TLV value perhaps?) which octets are to be zeroed out before the ICV is
> calculated.
> >
> > The way I understand that approach, it wouldn’t warrant any action from
> AODVv2 besides saying “if you calculate the ICV, set the Metric value to
> zero” (leaving the nitty gritty of how this would be done in detail to
> future work)… Is that correct?
> >
> >>
> >> We do not have the time to specify this in an acceptable manner within
> two weeks though. But the security consideration section could say
> something along the lines of "this enables the use of an ICV defined to
> zero out these octets“.
> >
> > Okay. :)
> >
> > Best regards,
> > Lotte
> >
> >>
> >> --
> >> Christopher Dearlove
> >> ----------------------! WARNING ! ---------------------- This message
> originates from outside our organisation, either from an external partner
> or from the internet.
> >> Follow the 'Report Suspicious Emails' link on IT matters for
> instructions on reporting suspicious email messages.
> >> D’oh, right. Yeah, if I remember it correctly, that’s what you
> explained to me when I got confused about the topic last spring… But– even
> if a message contains TLVs that the AODVv2 implementation handling it
> doesn’t understand, it will still be able to recognize the Metric TLV,
> right? Isn’t that the nifty thing about RFC5444? So, while we really
> shouldn’t write “before calculating the ICV, set the n-th 4 octets to 0”,
> we might say “identify the octets that make up the metric value and set
> those to 0”?
> >>
> >> Best regards,
> >> Lotte
> >>
> >>> Henning Rogge
> >>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 22 Apr 2016 16:40:06 +0200

That was my line of thinking, too, as it would allow enormous flexibility in the experiments possible - which definitely is required. 

Thomas

> On 22 avr. 2016, at 16:35, Justin Dean <[email-masked]> wrote:
> 
> Speaking as participant.
> 
> I kind of like the idea of using the experimental message type space.  We only have a limited amount of these message types.  The TLV assignments could just use the message type specific space and there isn't an issue there.  IANA wouldn't assign a number but I don't see why the document couldn't specify the experimental numbers it was going to use so other future near term experiential protocols could do the same and generally avoid conflict.  If the experiment is successful IANA assignments could be made.  Functionally no real difference with protections vs long term usage of limited space.
> 
> Justin
> 
>> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <[email-masked]> wrote:

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 22 Apr 2016 10:40:09 -0400

> made.  Functionally no real difference with protections vs long term usage

+1 here.

Regards,
Stan

>> But chewing up messages types (how many, 3?) of which there are
>> relatively few for experimental is long term a problem, although short term
>> not.
>>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 22 Apr 2016 14:41:59 +0000

I have no problem with that. I was trying to lay out the issues without muddying the water with my preference.

From: Justin Dean [mailto:[email-masked]]
Sent: 22 April 2016 15:35
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

*** WARNING ***

Justin

On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
There's rather a contradiction between the concepts of a definition of a protocol, even Experimental, and experimental space, which usually assumes that the user can do what he or she likes in it.

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

-----Original Message-----
From: Thomas Heide Clausen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 22 April 2016 14:21
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

> On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
>

Yep.

Thomas

> T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>
>
> From: Lotte Steenbrink [mailto:[email-masked]<mailto:[email-masked]>]
>> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>:
>>
>> From: manet [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Lotte
>> Steenbrink
>>> Am 22.04.2016 um 11:08 schrieb Henning Rogge <[email-masked]<mailto:[email-masked]>>:
>>>
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>> Hi Thomas,

---

From: Lotte Steenbrink <[email-masked]>
Date: Fri, 22 Apr 2016 18:26:56 +0200

Hi all,
to summarize:

* AODVv2 message Type numbers should be in the Experimental type space and the AODVv2 TLV Types should be message type-specific. This also means changing the text regarding IANA actions and changing the text regarding what the experiment is to something along the lines of “we want to gather experience on how to make generic metric TLVs and ICVs that work with changing metric TV values happen with reactive protocols”
* we’re undecided on (to quote Christopher) the "here's a mechanism we haven't really thought through in detail, but at least we've defined one", or "we know the sort of thing we want, and we'll describe it, but rather than produce something not quite right, we'll not go further“ decision on temporarily setting the metric value to 0 (i.e. the who and how). (personally, I think I’d prefer the latter approach, but that’s an entirely gut feeling-based preference)

Did I catch that correctly? If so, I’ll put together and suggest some text for the first point as soon as I get home and in case there has been a decision on the second by then, I’ll try to tackle that one too. :)

Best regards, Lotte

> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <[email-masked]>:
> 
> From: Justin Dean [mailto:[email-masked] <mailto:[email-masked]>] 
> On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
> T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> 
> From: Thomas Heide Clausen [mailto:[email-masked] <mailto:[email-masked]>]
> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > T:  +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>  |  E: [email-masked] <mailto:[email-masked]>
> >
> > From: Lotte Steenbrink [mailto:[email-masked] <mailto:[email-masked]>]
> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>>:
> >>
> >> From: manet [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Lotte
> >> Steenbrink
> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge <[email-masked] <mailto:[email-masked]>>:
> >>>
> >>> <[email-masked] <mailto:[email-masked]>> wrote:
> >>>> Hi Thomas,

---

From: Lotte Steenbrink <[email-masked]>
Date: Wed, 27 Apr 2016 23:46:09 +0200

Hi all,
I’m currently revising the security considerations with regards to the move from regeneration to forwarding, which depends on a decision being made on how/where we want to mention the possibility of zeroing out TLVs to calculate the ICV for the rest of a message’s contents (see second * of my last e-mail). I’ve not found a decision on this in other thread (please pardon me if I overlooked something), so I’ll bump this thread and ask the WG for its opinions. (again, personally, the 2nd option outlined by Christopher seems more appealing to me)

Regards,
Lotte

> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <[email-masked]>:
> 
> Hi all,
> to summarize:
> 
>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>>:
>>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 27 Apr 2016 23:16:32 +0100

The more you have to zero out, the messier it gets, and the less secure it gets (more things can be spoofed). I think that's about all I've got to add.

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

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)
> On 27 Apr 2016, at 22:46, Lotte Steenbrink <[email-masked]> wrote:
> 
> Hi all,
>>> For information regarding Red Flags that you can look out for in emails you receive, click here.
>>> If you feel the email is suspicious, please follow this process.
>>> 
>>> Speaking as participant.
>>>

---

From: Lotte Steenbrink <[email-masked]>
Date: Thu, 28 Apr 2016 00:19:51 +0200

> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <[email-masked]>:
> 

Of course. My question was just:
* Do we want to come up with an exact description of how the zeroing out should work now, with the short time we have left?
or
* Do we mention in the draft that zeroing out has to happen somehow and leave the nitty gritty to future work?

At least that’s how I understood the options you laid out...

> -- 
> Christopher Dearlove
> [email-masked] <mailto:[email-masked]> (iPhone)
> [email-masked] <mailto:[email-masked]> (home)
> 
> 
> 
> --  
> Christopher Dearlove
> [email-masked] <mailto:[email-masked]> (iPhone)
> [email-masked] <mailto:[email-masked]> (home)
> On 27 Apr 2016, at 22:46, Lotte Steenbrink <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Hi all,
>>> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <[email-masked] <mailto:[email-masked]>>:
>>> 
>>> Hi all,
>>> to summarize:
>>>

---

From: Jiazi YI <[email-masked]>
Date: Thu, 28 Apr 2016 00:43:25 +0200

On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink <
[email-masked]> wrote:

> The more you have to zero out, the messier it gets, and the less secure it
> gets (more things can be spoofed). I think that's about all I've got to add.
>
>
> * Do we want to come up with an exact description of how the zeroing out
> should work now, with the short time we have left?
>

If a meaningful security mechanism is required, yes.
I think the first thing to do is to cut as many mutable fields and optional
fields as possible.

best

Jiazi

> I’m currently revising the security considerations with regards to the
> move from regeneration to forwarding, which depends on a decision being
> made on how/where we want to mention the possibility of zeroing out TLVs to
> calculate the ICV for the rest of a message’s contents (see second * of my
> last e-mail). I’ve not found a decision on this in other thread (please
> pardon me if I overlooked something), so I’ll bump this thread and ask the
> WG for its opinions. (again, personally, the 2nd option outlined by
> Christopher seems more appealing to me)
>
> Regards,
> Lotte
>
> * AODVv2 message Type numbers should be in the Experimental type space and
> the AODVv2 TLV Types should be message type-specific. This also means
> changing the text regarding IANA actions and changing the text regarding
> what the experiment is to something along the lines of “we want to gather
> experience on how to make generic metric TLVs and ICVs that work with
> changing metric TV values happen with reactive protocols”
> * we’re undecided on (to quote Christopher) the "here's a mechanism we
> haven't really thought through in detail, but at least we've defined one",
> or "we know the sort of thing we want, and we'll describe it, but rather
> than produce something not quite right, we'll not go further“ decision on
> temporarily setting the metric value to 0 (i.e. the who and how).
> (personally, I think I’d prefer the latter approach, but that’s an entirely
> gut feeling-based preference)
>
> Did I catch that correctly? If so, I’ll put together and suggest some text
> for the first point as soon as I get home and in case there has been a
> decision on the second by then, I’ll try to tackle that one too. :)
>
> Best regards, Lotte
>
> *--*
> *Christopher DearloveSenior Principal EngineerBAE Systems Applied
> Intelligence Laboratories*
>
> *__________________________________________________________________________*
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> *From:* Justin Dean [mailto:[email-masked] <[email-masked]>]
> *Sent:* 22 April 2016 15:35
> *To:* Dearlove, Christopher (UK)
> *Cc:* Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
> *Subject:* Re: [manet] On Forwarding-and-regeneration (was: Re:
> **** 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>.*
> Speaking as participant.
>

---

From: Justin Dean <[email-masked]>
Date: Wed, 27 Apr 2016 23:24:59 +0000

An alternative solution to checking integrity. The current icv draft is
good at validating messages from an original source. OLSRV2 and NHDP use
this to good effect. AODVV2 doesn't because the messages are regenerated; I
belive this to be the correct term as the message contains local
information, path information, and originator information. Getting the icv
draft to work on forwarded packets is ugly as they really are regenerated
and should be. What we want to do is secure the original source of
information which is OrigAddr/target address and sequence number. Why not
just attach a new aodv specific icv TLV which uses THAT info and nothing
else? The current icv TLV would/could still be used over the whole message
hop by hop by each router, as the messages are regenerated.

Justin

On Wed, Apr 27, 2016, 6:43 PM Jiazi YI <[email-masked]> wrote:

>> The more you have to zero out, the messier it gets, and the less secure
>> it gets (more things can be spoofed). I think that's about all I've got to
>> add.
>>
>>
> I think the first thing to do is to cut as many mutable fields and
> optional fields as possible.
>
> best
>
> Jiazi
>
>
>> or
>> * AODVv2 message Type numbers should be in the Experimental type space
>> and the AODVv2 TLV Types should be message type-specific. This also means
>> Did I catch that correctly? If so, I’ll put together and suggest some
>> text for the first point as soon as I get home and in case there has been a
>> attachments or reply.For information regarding **Red Flags** that you
>> can look out for in emails you receive, click here

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 28 Apr 2016 01:38:03 +0200

I've argued in a few emails why that is a very bad idea:

1) any experiment developing extensions  will require to also update the specification for how to calculating the ICV, throwing backwards/forwards interoperability out the window.

2) the simple solution is to *not* "regenerate" messages (it is simply not necessary) but forward unmodified (preserving lay out, strictly) messages with "well defined mutable fields" (such as "a value of a TLV") which would (since we are not regenerating) be at the same place in the byte stream: at the sender, at the recipient, and at all intermediaries. That allows for extensions (as added by the source) to be covered by the ICV, *and* enables experiments also with advanced stuff such as aggregate signatures, etc.

The whole "regeneration" approach doesn't bring anything, and complicates security considerably.

Sent from my iPad

> On 28 Apr 2016, at 01:24, Justin Dean <[email-masked]> wrote:
> 
> An alternative solution to checking integrity. The current icv draft is good at validating messages from an original source. OLSRV2 and NHDP use this to good effect. AODVV2 doesn't because the messages are regenerated; I belive this to be the correct term as the message contains local information, path information, and originator information. Getting the icv draft to work on forwarded packets is ugly as they really are regenerated and should be. What we want to do is secure the original source of information which is OrigAddr/target address and sequence number. Why not just attach a new aodv specific icv TLV which uses THAT info and nothing else? The current icv TLV would/could still be used over the whole message hop by hop by each router, as the messages are regenerated.
> 
> Justin
> 
> 
>>> On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink <[email-masked]> wrote:
>>> 
>> I think the first thing to do is to cut as many mutable fields and optional fields as possible. 
>> 
>> best
>> 
>> Jiazi
>>  
>>> or

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 28 Apr 2016 01:39:58 +0200

> On 28 Apr 2016, at 00:19, Lotte Steenbrink <[email-masked]> wrote:
> 
> 

Absolutely required for interoperability, yes.
And...for passing WGLC, and for (I suspect) satisfying the SEC-DIR and SEC-ADs.

Thomas

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 27 Apr 2016 17:04:40 -0700

Hello Justin,

I think a new AODV-specific ICV is probably the right answer.  It would 
be nice to get some help generating the proper settings for all of the 
RFC 7182 fields to support this approach.  If not that, could we fall 
back on RFC 4868, which seems pretty straightforward?

Regards,
Charlie P.

On 4/27/2016 4:24 PM, Justin Dean wrote:
>
> An alternative solution to checking integrity. The current icv draft 
> is good at validating messages from an original source. OLSRV2 and 
> NHDP use this to good effect. AODVV2 doesn't because the messages are 
> regenerated; I belive this to be the correct term as the message 
> contains local information, path information, and originator 
> information. Getting the icv draft to work on forwarded packets is 
> ugly as they really are regenerated and should be. What we want to do 
> is secure the original source of information which is OrigAddr/target 
> address and sequence number. Why not just attach a new aodv specific 
> icv TLV which uses THAT info and nothing else? The current icv TLV 
> would/could still be used over the whole message hop by hop by each 
> router, as the messages are regenerated.
>
> Justin
>
>
> On Wed, Apr 27, 2016, 6:43 PM Jiazi YI <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>>         Am 28.04.2016 um 00:16 schrieb Christopher Dearlove
>>         <[email-masked]
>>         <mailto:[email-masked]>>:
>>
>>         The more you have to zero out, the messier it gets, and the
>>         less secure it gets (more things can be spoofed). I think
>>         that's about all I've got to add.
>>
>
>         * Do we want to come up with an exact description of how the
>         zeroing out should work now, with the short time we have left?
>
>
>         * Do we mention in the draft that zeroing out has to happen
>         somehow and leave the nitty gritty to future work?
>
>>         [email-masked]
>>         <mailto:[email-masked]> (iPhone)
>>         [email-masked]
>>         <mailto:[email-masked]> (home)
>>
>>
>>
>>         -- 
>>         Christopher Dearlove
>>         [email-masked]
>>         <mailto:[email-masked]> (iPhone)
>>         [email-masked]
>>         <mailto:[email-masked]> (home)
>>         On 27 Apr 2016, at 22:46, Lotte Steenbrink
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>>         Hi all,
>>>         I’m currently revising the security considerations with
>>>         regards to the move from regeneration to forwarding, which
>>>         depends on a decision being made on how/where we want to
>>>         mention the possibility of zeroing out TLVs to calculate the
>>>         ICV for the rest of a message’s contents (see second * of my
>>>         last e-mail). I’ve not found a decision on this in other
>>>         thread (please pardon me if I overlooked something), so I’ll
>>>         bump this thread and ask the WG for its opinions. (again,
>>>         personally, the 2nd option outlined by Christopher seems
>>>         more appealing to me)
>>>
>>>         Regards,
>>>         Lotte
>>>
>>>>         Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink
>>>>         <[email-masked]
>>>>         <mailto:[email-masked]>>:
>>>>
>>>>         Hi all,
>>>>         to summarize:
>>>>
>>>>         * AODVv2 message Type numbers should be in the Experimental
>>>>         type space and the AODVv2 TLV Types should be message
>>>>         type-specific. This also means changing the text regarding
>>>>         IANA actions and changing the text regarding what the
>>>>         experiment is to something along the lines of “we want to
>>>>         gather experience on how to make generic metric TLVs and
>>>>         ICVs that work with changing metric TV values happen with
>>>>         reactive protocols”
>>>>         * we’re undecided on (to quote Christopher) the "here's a
>>>>         mechanism we haven't really thought through in detail, but
>>>>         at least we've defined one", or "we know the sort of thing
>>>>         we want, and we'll describe it, but rather than produce
>>>>         something not quite right, we'll not go further“ decision
>>>>         on temporarily setting the metric value to 0 (i.e. the who
>>>>         and how). (personally, I think I’d prefer the latter
>>>>         approach, but that’s an entirely gut feeling-based preference)
>>>>
>>>>         Did I catch that correctly? If so, I’ll put together and
>>>>         suggest some text for the first point as soon as I get home
>>>>         and in case there has been a decision on the second by
>>>>         then, I’ll try to tackle that one too. :)
>>>>
>>>>         Best regards, Lotte
>>>>
>>>>>         Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK)
>>>>>         <[email-masked]
>>>>>         <mailto:[email-masked]>>:
>>>>>
>>>>>         I have no problem with that. I was trying to lay out the
>>>>>         issues without muddying the water with my preference.
>>>>>
>>>>>         *--*
>>>>>
>>>>>         *Christopher Dearlove
>>>>>         **__________________________________________________________________________
>>>>>         *
>>>>>         *T*: +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>
>>>>>          | *E:[email-masked]
>>>>>         <mailto:[email-masked]>
>>>>>
>>>>>         BAE Systems Applied Intelligence, Chelmsford Technology
>>>>>         Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>>>>         *From:*Justin Dean [mailto:[email-masked]]
>>>>>         *Sent:*22 April 2016 15:35
>>>>>         *To:*Dearlove, Christopher (UK)
>>>>>         *Cc:*Thomas Heide Clausen; Mobile Ad Hoc Networks mailing list
>>>>>         *Subject:*Re: [manet] On Forwarding-and-regeneration (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, clickhere
>>>>>         <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.//
>>>>>         /If you feel the email is suspicious, please followthis
>>>>>         process
>>>>>         <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.//
>>>>>
>>>>>         Speaking as participant.
>>>>>
>>>>>         I kind of like the idea of using the experimental message
>>>>>         type space.  We only have a limited amount of these
>>>>>         message types.  The TLV assignments could just use the
>>>>>         message type specific space and there isn't an issue
>>>>>         there. IANA wouldn't assign a number but I don't see why
>>>>>         the document couldn't specify the experimental numbers it
>>>>>         was going to use so other future near term experiential
>>>>>         protocols could do the same and generally avoid conflict. 
>>>>>         If the experiment is successful IANA assignments could be
>>>>>         made. Functionally no real difference with protections vs
>>>>>         long term usage of limited space.
>>>>>         Justin
>>>>>         On Fri, Apr 22, 2016 at 9:35 AM, Dearlove, Christopher
>>>>>         (UK) <[email-masked]
>>>>>         <mailto:[email-masked]>> wrote:
>>>>>         There's rather a contradiction between the concepts of a
>>>>>         definition of a protocol, even Experimental, and
>>>>>         experimental space, which usually assumes that the user
>>>>>         can do what he or she likes in it.
>>>>>
>>>>>         But chewing up messages types (how many, 3?) of which
>>>>>         there are relatively few for experimental is long term a
>>>>>         problem, although short term not.
>>>>>
>>>>>         TLV space is easier in two regards. It's bigger (though
>>>>>         the prime real estate of type extension zero isn't) and
>>>>>         can have message type specific TLVs.
>>>>>
>>>>>         So TLVS can actually be invisible, if that option is
>>>>>         chosen. For messages something has to give. Least bad
>>>>>         option is again one of those we should discuss, but time ...
>>>>>
>>>>>         (To be precise, messages types from 224 are defined in RFC
>>>>>         5444 as " Experimental Use", of which BCP 26 says "Similar
>>>>>         to private or local use only, with the  purpose being to
>>>>>         facilitate experimentation." The alternative 0-223 space
>>>>>         is Expert Review. IANA still thinks the experts are Joe
>>>>>         Macker and the recused Stan Ratliff. But that's a soluble
>>>>>         nit.)
>>>>>
>>>>>         --
>>>>>         Christopher Dearlove
>>>>>         T: +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194> |
>>>>>          E:[email-masked]
>>>>>         <mailto:[email-masked]>
>>>>>
>>>>>         BAE Systems Applied Intelligence, Chelmsford Technology
>>>>>         Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>>>>         Subject: Re: [manet] On Forwarding-and-regeneration (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 from the internet.
>>>>>         Follow the 'Report Suspicious Emails' link on IT matters
>>>>>         for instructions on reporting suspicious email messages.
>>>>>         > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK)
>>>>>         <[email-masked]
>>>>>         <mailto:[email-masked]>> wrote:
>>>>>         >
>>>>>         > Once you're entirely in AODV2's own space, and AODVv2 is
>>>>>         experimental (working assumption for this discussion) you
>>>>>         have more liberty.
>>>>>         >
>>>>>
>>>>>         Yep.
>>>>>
>>>>>         Taken somewhat by surprise both by the sudden "rush" and
>>>>>         the experimental maturity level, I am wondering (and
>>>>>         haven't thought through) about experimental space vs
>>>>>         non-experimental (for message types, and consequently for
>>>>>         message type specific TLV types).
>>>>>
>>>>>         I think that if the AODVv2 experiment specifies the use of
>>>>>         Message types from the Experimental message type space
>>>>>         without making actual registrations in the IANA registry,
>>>>>         AND the use of type specific TLV types, this becomes a
>>>>>         non-issue entirely (by design, this is precisely what that
>>>>>         Whereas, as you point out, the alternative is a "can open
>>>>>         - worms everywhere" situation that I think time is too
>>>>>         short to solve?
>>>>>
>>>>>         Thomas
>>>>>
>>>>>
>>>>>         > Then you could try specifying it. But with a very good
>>>>>         chance of producing something you later decide you should
>>>>>         have done differently.
>>>>>         >
>>>>>         > I honestly don't know which would go down better (or
>>>>>         less badly) - "here's a mechanism we haven't really
>>>>>         thought through in detail, but at least we've defined
>>>>>         one", or "we know the sort of thing we want, and we'll
>>>>>         describe it, but rather than produce something not quite
>>>>>         right, we'll not go further".
>>>>>         >
>>>>>         > --
>>>>>         > Christopher Dearlove
>>>>>         > T: +44 (0)1245 242194 <tel:%2B44%20%280%291245%20242194>
>>>>>         |  E:[email-masked]
>>>>>         <mailto:[email-masked]>
>>>>>         >
>>>>>         > BAE Systems Applied Intelligence, Chelmsford Technology
>>>>>         Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>>>>         > From: Lotte Steenbrink
>>>>>         [mailto:[email-masked]
>>>>>         <mailto:[email-masked]>]
>>>>>         > Subject: Re: [manet] On Forwarding-and-regeneration
>>>>>         (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 from the internet.
>>>>>         > Follow the 'Report Suspicious Emails' link on IT matters
>>>>>         for instructions on reporting suspicious email messages.
>>>>>         >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher
>>>>>         (UK) <[email-masked]
>>>>>         <mailto:[email-masked]>>:
>>>>>         >>
>>>>>         >> Just be careful to note that this concept is as
>>>>>         currently being discussed (a) specific to AODVv2, and (b)
>>>>>         not an application of 7182, which has no knowledge of
>>>>>         special TLVs.
>>>>>         >>
>>>>>         >> This is something we'd want to get right, and need to
>>>>>         get right if in any space not specific to ADODVv2, because
>>>>>         getting it wrong produces future problems.
>>>>>         >
>>>>>         > Makes sense.
>>>>>         >
>>>>>         >> To indicate the range that's open, here are two
>>>>>         possible ideas, one of which has an impact now, so needs
>>>>>         to be agreed. Note that I'm not suggesting (in fact quite
>>>>>         the opposite) defining an extension to 7182 here, rather
>>>>>         enabling such an extension, if written, to "do the right
>>>>>         thing".
>>>>>         >> - We have an extension to 7182 that says "zero out all
>>>>>         value octets in protocol specific TLVs. That requires now
>>>>>         putting the AODVv2 metric TLV in that space.
>>>>>         >
>>>>>         > Just to make sure that I understood you correctly– “that
>>>>>         space” meaning making the AODVv2 metric TLV protocol
>>>>>         specific? (By “the aodvv2 metric tlv” I’m referring to the
>>>>>         generic TLV we’ve been talking about on this list earlier
>>>>>         this week).
>>>>>         >
>>>>>         >> - We have an extension to 7182 that adds extra material
>>>>>         to the value field that indicates (TBD how, by position
>>>>>         with sanity check that this is TLV value perhaps?) which
>>>>>         octets are to be zeroed out before the ICV is calculated.
>>>>>         >
>>>>>         > The way I understand that approach, it wouldn’t warrant
>>>>>         any action from AODVv2 besides saying “if you calculate
>>>>>         the ICV, set the Metric value to zero” (leaving the nitty
>>>>>         gritty of how this would be done in detail to future
>>>>>         work)… Is that correct?
>>>>>         >
>>>>>         >>
>>>>>         >> We do not have the time to specify this in an
>>>>>         acceptable manner within two weeks though. But the
>>>>>         security consideration section could say something along
>>>>>         the lines of "this enables the use of an ICV defined to
>>>>>         zero out these octets“.
>>>>>         >
>>>>>         > Okay. :)
>>>>>         >
>>>>>         > Best regards,
>>>>>         > Lotte
>>>>>         >
>>>>>         >>
>>>>>         >> --
>>>>>         >> Christopher Dearlove
>>>>>         >> T: +44 (0)1245 242194
>>>>>         <tel:%2B44%20%280%291245%20242194>  | 
>>>>>         E:[email-masked]
>>>>>         <mailto:[email-masked]>
>>>>>         >>
>>>>>         >> BAE Systems Applied Intelligence, Chelmsford Technology
>>>>>         Park, Great Baddow, Chelmsford, Essex CM2 8HN.
>>>>>         >> From: manet [mailto:[email-masked]
>>>>>         <mailto:[email-masked]>] On Behalf Of Lotte
>>>>>         >> Steenbrink
>>>>>         >> ----------------------! WARNING !
>>>>>         ---------------------- This message originates from
>>>>>         outside our organisation, either from an external partner
>>>>>         or from the internet.
>>>>>         >> Follow the 'Report Suspicious Emails' link on IT
>>>>>         matters for instructions on reporting suspicious email
>>>>>         messages.
>>>>>         >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge
>>>>>         <[email-masked] <mailto:[email-masked]>>:
>>>>>         >>>
>>>>>         >>> <[email-masked]
>>>>>         <mailto:[email-masked]>> wrote:
>>>>>         >>>> Hi Thomas,
>>>>>         >> D’oh, right. Yeah, if I remember it correctly, that’s
>>>>>         what you explained to me when I got confused about the
>>>>>         topic last spring… But– even if a message contains TLVs
>>>>>         that the AODVv2 implementation handling it doesn’t
>>>>>         understand, it will still be able to recognize the Metric
>>>>>         TLV, right? Isn’t that the nifty thing about RFC5444? So,
>>>>>         while we really shouldn’t write “before calculating the
>>>>>         ICV, set the n-th 4 octets to 0”, we might say “identify
>>>>>         the octets that make up the metric value and set those to 0”?
>>>>>         >>
>>>>>         >> Best regards,
>>>>>         >> Lotte
>>>>>         >>
>>>>>         >>> Henning Rogge
>>>>>         >>

---

From: Jiazi YI <[email-masked]>
Date: Thu, 28 Apr 2016 14:14:23 +0200

I think it will make the specification complex, and hard to extend.

What about if I need to define a new TLV field for my extension? The field
would either be unprotected, or the extension won't be interoperable with
old implementations.

Jiazi

On Thu, Apr 28, 2016 at 2:04 AM, Charlie Perkins <
[email-masked]> wrote:

> Hello Justin,
>
> I think a new AODV-specific ICV is probably the right answer.  It would be
> nice to get some help generating the proper settings for all of the RFC
> 7182 fields to support this approach.  If not that, could we fall back on
> RFC 4868, which seems pretty straightforward?
>
> Regards,
> Charlie P.
> On Wed, Apr 27, 2016, 6:43 PM Jiazi YI < <[email-masked]>
> [email-masked]> wrote:
>
>> <[email-masked]>[email-masked]> wrote:
>>
>>>
>>> Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <
>>> <[email-masked]>[email-masked]>:
>>>
>>> On 27 Apr 2016, at 22:46, Lotte Steenbrink <
>>> <[email-masked]>[email-masked]> wrote:
>>>
>>> Hi all,
>>> Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <
>>> <[email-masked]>[email-masked]>:
>>>
>>> Hi all,
>>> to summarize:
>>>
>>> Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <
>>> <[email-masked]>[email-masked]>:
>>>
>>> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
>>> Intelligence Laboratories *
>>> *T*:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  *E: *
>>> <[email-masked]>[email-masked]
>>>
>>> <http://www.baesystems.com/ai>www.baesystems.com/ai
>>> *From:* Justin Dean [ <[email-masked]>mailto:[email-masked]
>>> <[email-masked]>]
>>> * Consider carefully whether you should click on any links, open any
>>> attachments or reply. For information regarding **Red Flags** that you
>>> * If you feel the email is suspicious, please follow this process
>>> I kind of like the idea of using the experimental message type space.
>>> We only have a limited amount of these message types.  The TLV assignments
>>> <[email-masked]>[email-masked]> wrote:
>>> So TLVS can actually be invisible, if that option is chosen. For
>>> messages something has to give. Least bad option is again one of those we
>>> should discuss, but time ...
>>>
>>> T:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  E:
>>> <[email-masked]>[email-masked]
>>>
>>> <http://www.baesystems.com/ai>www.baesystems.com/ai
>>> From: Thomas Heide Clausen [mailto: <[email-masked]>
>>> [email-masked]]
>>> > On 22 avr. 2016, at 15:05, Dearlove, Christopher (UK) <
>>> <[email-masked]>[email-masked]> wrote:
>>> >
>>> Taken somewhat by surprise both by the sudden "rush" and the
>>> experimental maturity level, I am wondering (and haven't thought through)
>>> about experimental space vs non-experimental (for message types, and
>>> consequently for message type specific TLV types).
>>>
>>> > T:  +44 (0)1245 242194 <%2B44%20%280%291245%20242194>  |  E:
>>> <[email-masked]>[email-masked]
>>> >
>>> >  <http://www.baesystems.com/ai>www.baesystems.com/ai
>>> > From: Lotte Steenbrink [mailto: <[email-masked]>
>>> [email-masked]]
>>> >> Am 22.04.2016 um 11:57 schrieb Dearlove, Christopher (UK) <
>>> <[email-masked]>[email-masked]>:
>>> >>
>>> >> To indicate the range that's open, here are two possible ideas, one
>>> of which has an impact now, so needs to be agreed. Note that I'm not
>>> >> - We have an extension to 7182 that says "zero out all value octets
>>> in protocol specific TLVs. That requires now putting the AODVv2 metric TLV
>>> in that space.
>>> >
>>> > Just to make sure that I understood you correctly– “that space”
>>> meaning making the AODVv2 metric TLV protocol specific? (By “the aodvv2
>>> metric tlv” I’m referring to the generic TLV we’ve been talking about on
>>> this list earlier this week).
>>> >
>>> > The way I understand that approach, it wouldn’t warrant any action
>>> from AODVv2 besides saying “if you calculate the ICV, set the Metric value
>>> to zero” (leaving the nitty gritty of how this would be done in detail to
>>> >> We do not have the time to specify this in an acceptable manner
>>> within two weeks though. But the security consideration section could say
>>> >> T:  +44 (0)1245 242194  |  E:  <[email-masked]>
>>> [email-masked]
>>> >>
>>> >>  <http://www.baesystems.com/ai>www.baesystems.com/ai
>>> >> From: manet [mailto: <[email-masked]>[email-masked]]
>>> On Behalf Of Lotte
>>> >> Steenbrink
>>> >>> Am 22.04.2016 um 11:08 schrieb Henning Rogge < <[email-masked]>
>>> [email-masked]>:
>>> >>>
>>> >>> < <[email-masked]>[email-masked]>
>>> wrote:
>>> >>>> Hi Thomas,
>>> >>  <[email-masked]>[email-masked]
>>> >>  <https://www.ietf.org/mailman/listinfo/manet>
>>> >  <[email-masked]>[email-masked]
>>> >  <https://www.ietf.org/mailman/listinfo/manet>
>>> <[email-masked]>[email-masked]
>>> <https://www.ietf.org/mailman/listinfo/manet>
>>> <[email-masked]>[email-masked]
>>> <https://www.ietf.org/mailman/listinfo/manet>
> manet mailing [email-masked]://www.ietf.org/mailman/listinfo/manet
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 28 Apr 2016 14:32:39 +0000

Playing devil’s advocate (because I don’t really like the idea) I think what you’d want is two TLVs. The first is something like 7182 ICV - potentially new ICV type extension(s) - that differs from existing ones by having the instruction “find the second TLV, if any, and remove it (as well as the ICV TLV) then use its value field that specifies which bytes to zero out, then check the ICV. I think you’d want to specify bytes to zero out by location, but constrain what they were allowed to zero out - just TLV value fields I think would be best.

This there could, if you went down the signature aggregation route Thomas has suggested be a different first TLV, using the same second TLV, which aggregates rather than zeros.

It would be much more powerful (for options like aggregation) if there was only ever one zeroed out part.

But two things. One is that the more you can zero out, the more attacks you open up. Thomas pointed out the “set a very small expiry time” one. Also while the above has been thought through a bit, it is not complete, not ready for prime time. It could be part of rechartered work, but not now. And the more flexible it is (more parts zeroed out, especially if not constrained) the more the security people will not like it.

What you could get away with in terms of handwaving to the future now, I don’t know.

From: manet [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 28 April 2016 13:14
To: Charlie Perkins
Cc: Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On Forwarding-and-regeneration

*** WARNING ***

What about if I need to define a new TLV field for my extension? The field would either be unprotected, or the extension won't be interoperable with old implementations.

Jiazi

On Thu, Apr 28, 2016 at 2:04 AM, Charlie Perkins <[email-masked]<mailto:[email-masked]>> wrote:

Hello Justin,

I think a new AODV-specific ICV is probably the right answer.  It would be nice to get some help generating the proper settings for all of the RFC 7182 fields to support this approach.  If not that, could we fall back on RFC 4868, which seems pretty straightforward?

Regards,
Charlie P.

Justin

On Wed, Apr 27, 2016, 6:43 PM Jiazi YI <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Apr 28, 2016 at 12:19 AM, Lotte Steenbrink <[email-masked]<mailto:[email-masked]>> wrote:

Am 28.04.2016 um 00:16 schrieb Christopher Dearlove <[email-masked]<mailto:[email-masked]>>:

best

Jiazi

or

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

--
Christopher Dearlove
[email-masked]<mailto:[email-masked]> (iPhone)
[email-masked]<mailto:[email-masked]> (home)
On 27 Apr 2016, at 22:46, Lotte Steenbrink <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
I’m currently revising the security considerations with regards to the move from regeneration to forwarding, which depends on a decision being made on how/where we want to mention the possibility of zeroing out TLVs to calculate the ICV for the rest of a message’s contents (see second * of my last e-mail). I’ve not found a decision on this in other thread (please pardon me if I overlooked something), so I’ll bump this thread and ask the WG for its opinions. (again, personally, the 2nd option outlined by Christopher seems more appealing to me)

Regards,
Lotte

Am 22.04.2016 um 18:26 schrieb Lotte Steenbrink <[email-masked]<mailto:[email-masked]>>:

Hi all,
to summarize:

Best regards, Lotte

Am 22.04.2016 um 16:41 schrieb Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>>:

*** WARNING ***

Justin

-----Original Message-----
From: Thomas Heide Clausen [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 22 April 2016 14:21
To: Dearlove, Christopher (UK)
Cc: Lotte Steenbrink; Mobile Ad Hoc Networks mailing list
Subject: Re: [manet] On Forwarding-and-regeneration (was: Re: draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items)

Yep.

Thomas

manet mailing list