[aodvv2-discuss] Re: [manet] AODVv2: Responses to Thomas Clausen's review comments

  • From: Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>
  • To: "aodvv2-discuss@xxxxxxxxxxxxx" <aodvv2-discuss@xxxxxxxxxxxxx>
  • Date: Tue, 15 Sep 2015 06:05:03 -0700


Hello folks,

Here is some discussion about Chris's responses. Your thoughts?


On 9/15/2015 2:57 AM, Dearlove, Christopher (UK) wrote:

A few observations on some of Victoria’s comments on Thomas’s comments.

Also, will a remote device be able to learn that IP1 and IP2 really are “the
same device” (or even, “the same interface”)?
- Not by using AODVv2. Moreover, for privacy reasons this is a good thing.
I’m not convinced by the moreover. In some systems, maybe. In others, not
convinced.

If this new requirement is placed on AODVv2, it can be met by another configuration step. Which, by the way, is probably missing in OLSRv2, and that would be a mistake for OLSRv2.

We can do it in a quite straightforward way. But as it would be a new requirement, we should not be penalized for meeting new requirements.


I strongly disagree with the assertion that in emergency and disaster relief
scenarios “the ability to communicate is more important than being assured of
secure operations” — I think that that’s an unfortunate and incorrect claim to
make.
I would also disagree with the original statement. At best it is sometimes true,
but I’m not aware of the sometimes. If we are talking about formal emergency
services, I would expect all three legs of the tripod – integrity, confidentiality
and availability – to be regarded as essential. The system would have whatever
cryptographic means needing to support I&C required and implemented, and the
system as a whole engineered to do the best possible for availability. (Or to
enable the likelihood of best possible in unknown circumstances.)

The only point is that in fact it is sometimes true, and that is what the Applicability statement is supposed to say.


- Our security is hop-by-hop and so the above doesn't seem to apply. We do
mention that encryption provides confidentiality.
It would appear hop by hop is the only option, so that and its implications
need to be summarised. With regard to confidentiality I think it’s important to
be clear what is confidential, data or the (AODVv2 and other) signalling.
Except by using a single shared secret, confidential routing signalling is
hard. (Though not impossible.)

AODVv2 is not charged with the requirement to enable confidentiality on the data plane. That is the job of IKEv2 and other such key distribution protocols.



Consequently, saying “use 6621 to reduce multicast overhead” is insufficient …
- We tried not to go too far into this earlier, but after Last Call begins we
would be happy to craft some text or perhaps another document for this purpose.
But the clarifying specification text will be very small, we think.

I think ensuring interoperability is something important before Last Call, not
after Last Call. I think the idea that that’s very small is optimistic. But if
it is very small, then before Last Call should be easy, and if it’s not it
needs to be before Last Call. Or you could take out and postpone to an
extension document. Drawback with that is that backward compatibility might
turn out to be a problem (unless you say “everyone must do this or not do
this”, whose acceptability could be discussed).

It is not within the jurisdiction of the AODVv2 specification to document applicability of RFC 6621 to a specific multicast group. The more I think about it, the more I believe that there is almost nothing to specify. But we could produce a document to clarify that there is almost nothing to specify. I'll try to fashion some text for the mailing list to make this clear. The small bit that needs to be said, which would take about one paragraph, is that for the purposes of flooding a RREQ, RFC 6621 techniques are applied as if the (source IP address, sequence number) ordered pair determines sameness of message. We already have the mechanism within AODVv2 for doing that anyway.

O.K. I will write this document next week.

Regards,
Charlie P.


Other related posts:

  1. Home
  2. aodvv2-discuss
  3. Archive
  4. 09-2015