Subject: Re: [manet] #45 (aodvv2): RFC 5498 non-compliance (submitted for Chris Dearlove)

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 8 Sep 2014 15:47:26 +0200

> On Mon, Jul 21, 2014 at 5:40 AM, manet issue tracker
> <[email-masked]<mailto:[email-masked]>>
> wrote:
> #45: RFC 5498 non-compliance (submitted for Chris Dearlove)
>
>  The document is completely noncompliant with the RFC 5444 multiplexing
>  mechanism, mandated by RFC 5498 (on the manet port/protocol). It does
>  many things that are not within its competence.
>
On 7/21/14, Charles E. Perkins <[email-masked]> wrote:
>
> Hello Chris,
>
> The document states:
>
>>    In its default mode of operation, AODVv2 sends messages using the
>>    parameters for port number and IP protocol specified in [RFC5498] to
>>    carry protocol packets.  By default, AODVv2 messages are sent with
>>    the IP destination address set to the link-local multicast address
>>    LL-MANET-Routers [RFC5498] unless otherwise specified. Therefore,
>>    all AODVv2 routers MUST subscribe to LL-MANET-Routers [RFC5498] to
>>    receiving AODVv2 messages.
>
> So, I suspect the problem lies elsewhere.  Could you point to the
> noncompliant part of the AODVv2 specification, and the protocol
> mandate for which the AODVv2 specification is noncompliant?
>

On 7/22/14, Dearlove, Christopher (UK) <[email-masked]> wrote:
> The quoted text is irrelevant to this point.
>
> As has been said many times, packets belong to the multiplexer, messages to
> the protocol. There are many pieces of text specifying things about packets
> that are out of the competence of the protocol. I'm afraid I stopped marking
> them on my copy.
>
> (For exactly how the protocol can interact with packets, see 5444.)
>

I don't think packets should only blong to multiplexer/parsers.
5444-Packets COULD be generated by protocols not only multiplexer.
IMHO, There is no specification that states that 5444-packets are
generated only by parsers/multiplexer (If I am wrong please point to
it). The RFC5444-packet is for the protocol-designer to define not the
parser-designer. The parser-designer needs to follow the
protocol-designer. You cannot force a router vendor to not define its
own 5444-packets for its routing protocol. I remember that within the
Packet-bb submission (now is RFC5444) there was a discussion between
Teco and Thomas that there are many issues related to parsing and
multiplexing that this RFC5444/Packet-bb-draft does not specify and
did not solve. This issue needs more discussion in the WG, because I
don't find consensus on the issue.

On 7/22/14, Dearlove, Christopher (UK) <[email-masked]> wrote:
> RFC5444 describes a multiplexing process. It is not required purely in its
> own terms.

Yes it is not required because RFC5444 is just format standard,
RFC5444 is not parsing standard, RFC5444 is not a packet-multiplex
standard. The multiplex in just explained in appendix which is not
normative, and IMHO the WG did not agree on specific multiplexing
standard. One participant yesterday mentioned the multiplex as in that
Appendix is a MUST, which I disagree.

> But RFC 5498 make it mandatory for any protocol using the
> port/protocol allocated by that RFC. And the WG has agreed that all routing
> protocols developed have to be able (at least) to use that port/protocol.

RFC5498 is for one one RFC5444 packet, please note that RFC5444 is a
general packet format, protocols can define their own
packets/messages. I understand that you suggest unifying the packet
for all MANET protocols but that is not specified in RFC5444. RFC5444
already states clearly that packets/messages are formated but parsing
is general-logic and independent from protocol. In IETF 5444 parsing
is not specified yet, just logic. see below:

{{{

The specification has been explicitly designed with the following
properties, listed in no particular order, in mind:

Parsing logic - The notation used in this specification facilitates
generic, protocol-independent parsing logic.

Extensibility - Packets and messages defined by a protocol using
this specification are extensible by defining new messages and new
TLVs. Protocols using this specification will be able to
correctly identify and skip such new messages and TLVs, while
correctly parsing the remainder of the packet and message.

}}}

It does not state unify parsing as general but just general parsing to
be independent, so we design AODVv2 independently from parsing and
even independent of multiplexing packets.

I suggest we work on this draft AODVv2 independently from
parsing/multiplexing as the RFC5444 suggested which AODVv2 uses
correctly so far by my understandning and no much answers received for
editor questions related to the draft.

Best Regards,
AB

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 8 Sep 2014 16:26:07 +0100

Really, I'm not wading through all that, as it becomes apparent early on that it misses the whole point.
- 5444 defines a packet/message format,
- 5444 defines how that can be used by a multiplexer. Yes, at this point that's optional.
- 5498 makes use of that multiplexing approach mandatory on the manet protocol/port.
- The WG (in agreement with ADs etc.) has decided that MANET routing protocols it designs are to use the manet protocol/port.

Put all that together, and you have the state of play. Doesn't matter if you don't think that's so or not. It is.

Of course anyone can use 5444 for some other purpose. Various options here. But none what's being discussed.

As for AODVv2 being noncompliant with 5444/5498, yes it is. It simple terms, packets belong to the multiplexer, messages belong to a protocol. So AODVv2 can define messages. It doesn't define packets. It can (and this is specified) get read access to the packet header, and (also specified) provide TLVs for the packet header as well as providing messages for packets. But that's not what's done either.

On 8 Sep 2014, at 14:47, Abdussalam Baryun wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: John Dowdell <[email-masked]>
Date: Mon, 08 Sep 2014 17:19:18 +0100

All

As part of ongoing author work on AODVv2, I am looking at the 
relationship between RFC5444 and AODVv2 right now. Hopefully we will 
have some material to discuss at the next meeting. In the meantime, 
constructive advice is welcome, both on and off-list.

John

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 08 Sep 2014 10:34:46 -0700

Hello Chris,

To my understanding, AODVv2 does indeed specify messages, not packets.
A long time ago, we had the luxury of sending packets, but for quite a while
now the AODVv2 specification has been rewritten to specify the messages
instead.  We will be happy to fix language in the specification 
remaining that
might be confusing.

A new revision should be out before long.  But if you want to check
the current version for this point, any constructive suggestions will be
appreciated.

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 8 Sep 2014 18:47:47 +0100

> To my understanding, AODVv2 does indeed specify messages, not packets.

Not the version that was current when I wrote my comments. I haven't checked if that was the most recent now or not. But it doesn't sound as if you are suggesting there have been recent changes in that area.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 08 Sep 2014 10:57:27 -0700

Hello Chris,

Yes, there have been several recent changes, included in the last
version, and most likely some more to be included in the upcoming
version.  The intention is to completely avoid any confusion.

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 8 Sep 2014 19:12:16 +0100

Well, you'll forgive me for commenting on the version that was newest when I made my original comments, not a then-future version.

A quick skim shows the second paragraph of section 5.4 is outside AODV's competence, but at the point I stopped skimming that was the main point I noted.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 08 Sep 2014 11:19:19 -0700

Hello Chris,

No offense taken, so no forgiveness needed.

I don't think that RFC 5444 procludes AODVv2
from specifying adherence to RFC 5082, if that was
the intention of your remark...

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 8 Sep 2014 19:57:51 +0100

Actually, it was. AODVv2 can't adhere to RFC 5082. It has to be the 5444 multiplexer that does or doesn't adhere to it. It's probably not specified whether it does or not (it certainly isn't specified that it does., It might say TTL = 1, I don't recall right now,

There are then choices:
- Write something new to mandate all implementations of the 5444 multiplexer to adhere to 5082. I would be strongly against that.
- Put a recommendation (i.e. a should) into AODVv2 that the 5444 multiplexer it uses should adhere to 5082. Not my first choice.
- Put a requirement (i.e a must) into AODVv22 that the 5444 multiplexer it uses must adhere to 5082. I would be strongly against that too.
- Leave it up to whoever implements the 5444 multiplexer, which already is required to fulfil the key requirement here (that packets only travel one logical hop - but physical hops?)

Te question is, why is AODVv2 any more needing of this than anything else? If it's not, then the issue definitely becomes one of point 4.

Now providing advice about the 5444 multiplexer, including any reference to 5082, is really the job of another document on broader 5444 advice. One that is bubbling up the 5444 authors' (at least) priority list. I don't have a position currently on what emphasis should be put on 5082 in such a document, and I don't know anyone else's views on that matter either.

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 08 Sep 2014 13:21:44 -0700

Hello Chris,

In general, if a routing protocol cannot specify TTL=255,
then something is definitely broken.  Message bundling
is not a good enough excuse for disabling this function.

AODVv2 specifically does need the functionality, and so
the general statement does have a relevant specific
example.

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 8 Sep 2014 21:58:21 +0100

Why does AODVv2 need this functionality any more than, say, NHDP, OLSRv2 or SMF? 5444 packets are meant to travel only one hop, it's part of the multiplexer design. If 5082 helps ensure this, this is something to apply at that level. This is not and cannot be an AODVv2 function, because AODVv2 isn't in change of packets.

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

> On 8 Sep 2014, at 21:21, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Chris,
>

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 8 Sep 2014 21:59:23 +0100

Why does AODVv2 need this functionality?

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 08 Sep 2014 14:18:54 -0700

Hello Chris,

AODVv2 needs the functionality because it relies on
reverse path forwarding.

AODVv2 should be able to control the dissemination of
AODVv2 messages, and since AODVv2 messages are contained
in packets, then it seems that AODVv2 ought to be able to
specify how packets containing AODVv2 messages are to
be disseminated.

In RFC 5444, one finds the following:

>     Messages are designed to be able to be forwarded over one or more
>     logical hops, in a new packet for each logical hop.  Each logical hop
>     may consist of one or more IP hops.

I admit that this passage may be interpreted in various different ways.
But to me it meant that AODVv2 needs to make sure that there would
just be one hop.  The term "logical hop" isn't defined in the document,
and I'm sure we could both write down multiple reasonable definitions
for the term.  Overlay networks come to mind, or multi-link Ethernet
media, or ...

Regards,
Charlie P.

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 8 Sep 2014 23:43:42 +0200

> On 08 Sep 2014, at 23:18, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Chris,
> 

Having designed reactive protocols within the RFC5444 framework, I can attest to the fact that there are no obstacles posed by the use of RFC5444-messages on this (or any other) points. Indeed, using RFC5444 messages for this is both straight-forward and intuitive.

There is absolutely no technical reason to want to "re-define" or "re-interpret", or "interpret in a non-generic, non-interoperable form" RFC5444. 

None. Nada. There's tons of running, deployed code that testifies to this.

Years have passed, and this point of RFC5444/RFC5498 compliance has been discussed, explained, explained again, and again, and again, yet we're still seeing a non-compliant specification, and we are still arguing this issue. With the same arguments brought forward by the current authors of the reactive protocol specification, and the same patient explanations from the WG participants.

I am utterly befuddled as to why the authors of this particular specification are so insistent on going against what appears to be overwhelming WG consensus, as well as the body of RFCs published by this WG. I even believe that one of the chairs, years ago (!), reminded the authors of this fact.

Respectfully,

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 8 Sep 2014 23:52:31 +0200

> On 08 Sep 2014, at 22:58, Christopher Dearlove <[email-masked]> wrote:
> 

The above is, probably, the most concise way of summarizing this fact. I am in full agreement with Chris here.

I'll add that, having designed and implemented reactive protocols using RFC5444, that it is perfectly feasible, even easy, to do so, and respect the 5498/5444 architecture.

Thomas

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 8 Sep 2014 22:59:39 +0100

This is no different to NHDP's requirements (which may use the IP packet source address). It is, as I have said, a 5444 multiplexing issue.

It does, I agree open up the question as to what one logical hop means precisely. Right now I forget why that distinction was put in 5444, I think was a requirement from outside the authors.

But this is not specific to AODVv2, nor does it make 5082 mandatory, that's just one way to achieve this. And it's just not acceptable for AODVv2 to attempt to control packets, because what if another protocol tries doing the same, inconsistently.

Rather the starting point should be what are the actual requirements (which are as you note about the properties that make reverse path forwarding working).

> On 8 Sep 2014, at 22:18, Charlie Perkins <[email-masked]> wrote:
> 
> Hello Chris,
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 9 Sep 2014 03:36:10 +0200

Just my last comment in this ticket.

> - 5498 makes use of that multiplexing approach mandatory on the manet
5498 does not specify for information-multiplexers but it specifies for
routing-protocols. Those allocations are owned by the routing protocols not
by the multiplexers. However, if we consider a use case of many routing
protocols sharing the MANET, then we must have unified multiplexer using
that allocated  port as 5498 state for routing.

RFC5498 can have an update to add another port with same ip number for
other purposes that mentions multiplexers use.

AB

---

From: Justin Dean <[email-masked]>
Date: Mon, 8 Sep 2014 21:51:51 -0400

I think that some of us are missing the forest while looking at the trees.
The reasons for RFC5498 multiplexing requirement IS important and we should
just go opening up/asking for new ports.  One of the reasons it's there is
that so multiple different MANET protocols can work with each other with
minimal issues.  We do this already with NHDP and OLSRv2 and NHDP and SMF
TLV extensions and it's a very good thing.

The root of the issue is assigning semantics to the order of the addresses
which AODVv2 currently does and in doing so breaks multiplexer
implementations (mine included) the work around of throwing out the
multiplexer to get around this is wrongheaded as there are also very good
reasons (one of which Henning pointed out, future proofing by containing
information within tlvs and not by position); Other reasons include,
multiplexer reuse which enables both multi-protocol packaging (fewer
packets), code reuse (minor), packet compression in the address blocks
(potential large gain), and packet compression in the TLV space (also
potential large gain).

We (read MANET wg) came up with these requirements for very specific
reasons and at this point I see no reason let alone any compelling reason
to ignore or work around them.  If AODVv2 can get this right and abide by
the MANET design requirements it will in fact be a better protocol for it;
these aren't trivial meaningless requirements.

Justin

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Sep 2014 06:33:29 +0200

> AODVv2 needs the functionality because it relies on

So you would say AODVv2 cannot work without the IP-TTL=255 setting? I
would disagree. IP-TTL=1 and/or a linklocal multicast address work
similarly.

I think the IP-TTL=255 is an optional "security feature" on RFC5444
packet level, trying to make it harder for computers more than one hop
away to deliver an IP packet (not impossible, there might be tricks
with IPIP tunnels that work). If this is true, it might fit into a
'security considerations' section or the document, or even better put
into a "RFC5444 packet security" draft" of its own, that describes
best practices and possible options how to handle the packet output of
the multiplexer for all protocols using RFC5444.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Sep 2014 07:52:24 +0200

On Tue, Sep 9, 2014 at 7:41 AM, Charlie Perkins
<[email-masked]> wrote:
>
> Hello Henning,
>
> I didn't say it could not work without TTL=255.

Good.

(skipping the rest of the paragraph)

> However, I think it is pretty bad when a message bundling system
> imposes these collateral constraints.  I reckon it was another
> unintended consequence.

requiring a certain IP-TTL is a constraint too.

> There's nothing wrong with attempting to use multiple security
> measures.  As far as I know, it's usually considered praiseworthy.

Its a BAD thing to make one weak security option mandatory as part of
the core protocol.

I don't see any real advantage of this TTL-magic, other then preparing
for a mesh node malfunctioning. Its strange on IPv4 and its even silly
on IPv6 where we have recognizable linklocal multicast addresses (the
LL_MANET multicast address is one of them). If you expect your
neighbor mesh nodes forwarding linklocal multicast traffic you have
other problems than looking at the TTL field.

Either put it into the "security considerations" as one option to do
it or write (as most other protocols of this WG) a security
considerations draft, either on protocol level or on RFC5444 packet
level.

Henning Rogge

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 08 Sep 2014 22:41:22 -0700

Hello Henning,

I didn't say it could not work without TTL=255.  Of course it can.
It could work if there is a constraint that the number of bytes in
any message must be a factor of 7.  It could work if there is a constraint
that there must be no more than 295 bits set to a value of '1'.

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Tue, 9 Sep 2014 07:29:51 +0100

And no one has said its a bad idea to use 5082 (though it's not the only option). Just that it's a 5444 multiplexer level decision, not an AODVv2 level decision.

> On 9 Sep 2014, at 06:41, Charlie Perkins <[email-masked]> wrote:
> 
> 
> Hello Henning,
>

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 10 Sep 2014 16:02:13 -0700

Hello Justin,

Follow up below, omitting some of your text...

On 9/8/2014 6:51 PM, Justin Dean wrote:
>
>
> The root of the issue is assigning semantics to the order of the 
> addresses which AODVv2 currently does

No, the addresses can appear in any order.  This was fixed a long time ago.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 10 Sep 2014 16:15:20 -0700

Hello Henning,

> requiring a certain IP-TTL is a constraint too.

This is mixing apples and oranges.

A *particular* routing protocol may well need be able to deal with
such matters.

An over-arching message-bundling protocol should never take
the permanent step of preventing all future routing protocols from
dealing with such matters.

> Its a BAD thing to make one weak security option mandatory as part of

That's debatable, and I wonder why RFC 5082 would be published if
it were as bad as you say.  Indeed, if one has a network where most
of the routers obey the rules, the security option works O.K. as
designed.

For your more general point, it's basically incorrect I think.  For
instance, a 12-foot brick wall with machine gun turrets would make
my front door lock seem to be quite puny.  And most people consider
it mandatory to lock their front door.

And, even a simple unlocked door ought to be closed to provide the
small bit of security against skunks walking in the house.

This is a quite useful analogy.  Many times, small steps to improve
security are indeed additive, even if none is perfect by itself. For a
trivial example, one security mechanism may only work for wrongs
in the vertical direction, and another may only protect against
wrongs in horizontal directions.  With another few minutes work,
I reckon I could exhibit more relevant examples and I strongly
suspect you could also.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 10 Sep 2014 16:17:11 -0700

Hello Chris,

> And no one has said its a bad idea to use 5082 (though it's not the only option). Just that it's a 5444 multiplexer level decision, not an AODVv2 level decision.

That's fine with me.  How do I instruct RFC 5444 to set TTL==255?

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 11 Sep 2014 00:53:57 +0100

Now it depends who "I" is. If "I" is the overall system design you can do it as part of that. If "I" is AODVv2, you don't. It's not within an individual routing protocol's competence. Like many other things.

> On 11 Sep 2014, at 00:17, Charlie Perkins <[email-masked]> wrote:
> 
> 
> Hello Chris,
>

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Sep 2014 07:24:42 +0200

> That's fine with me.  How do I instruct RFC 5444 to set TTL==255?

On protocol level? Put it into the right document (e.g. the "rfc5444
security practices" or whatever).

On implementation level? Just as you do now, just a line of code in
the right place.

Would be the "use IP-TTL 255 as an additional security measurement"
part of the AODVv2 protocol? No, because the protocol should only deal
with the messages so its easy to mix with the other protocols using
RFC5444 (e.g. NHDP for proactive neighborhood discovery and detection
of symmetric links). But of course it would be part of some (maybe not
all) AODVv2 implementations (some might implement other security
measurements).

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 11 Sep 2014 11:57:50 +0200

On Thursday, September 11, 2014, Henning Rogge wrote:

> <[email-masked] <javascript:;>> wrote:
> >
> > Hello Chris,
> >

For interoperability purposes the right place is within AODVv2
implementation. For independent purposes the right place is AODVv2. Chris
answered it as part of overall-system but still no definition for that as
IETF standard, so does that mean writing another draft to update the
system.

> of symmetric links).

Those protocols can be updated for AODVv2 functions. Those protocols are
servants to routing protocols so they should follow.

> But of course it would be part of some (maybe not

So do you agree the right place is AODVv2. Overall, this design problem is
because the WG wrongly decided to design the packet before the functions
and to make routing functions serve RFC5444 within a unified multiplex
method.

AB

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 11 Sep 2014 11:02:53 +0100

Henning is right, you are wrong. I could explain why, but that's already been done more than once.

> On 11 Sep 2014, at 10:57, Abdussalam Baryun <[email-masked]> wrote:
> 
> 
> 
> For interoperability purposes the right place is within AODVv2 implementation. For independent purposes the right place is AODVv2. Chris answered it as part of overall-system but still no definition for that as IETF standard, so does that mean writing another draft to update the system. 
>  
>> 
> Those protocols can be updated for AODVv2 functions. Those protocols are servants to routing protocols so they should follow. 
>  
> So do you agree the right place is AODVv2. Overall, this design problem is because the WG wrongly decided to design the packet before the functions and to make routing functions serve RFC5444 within a unified multiplex method. 
> 
> AB

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Sep 2014 12:21:34 +0200

On Thu, Sep 11, 2014 at 11:57 AM, Abdussalam Baryun
<[email-masked]> wrote:
> So do you agree the right place is AODVv2.

No, I do NOT.

Maybe you should try to read and understand my mail.

As I said, on protocol level (which means the RFCs defining the
protocol) the AODVv2 document is NOT the right place for this.

As for implementations... ALL routing protocol implementations are
drawing from multiple documents to do their job.

> Overall, this design problem is
> because the WG wrongly decided to design the packet before the functions and
> to make routing functions serve RFC5444 within a unified multiplex method.

The problem is that you just don't understand whats the reason behind
the document split.

In fact it would have been even better if the MPR handling woud also
have been split into its own document so it can be reused easier
without referring to the OLSRv2 RFC. Its works the way it is, but
splitting it would have been more elegant (but it would have delayed
OLSRv2 even more).

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 11 Sep 2014 12:12:31 +0100

Henning has addressed the other issues. I'll mention one.

> splitting it would have been more elegant (but it would have delayed

Completely agree. And in fact that's not the only thing I (we I believe) would have split out in an ideal world. Next on my list would be the processing and forwarding mechanism in OLSRv2 that is designed for use by message types other than just TC messages.

But we were delayed enough as it was.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 11 Sep 2014 13:15:52 +0200

> Completely agree. And in fact that's not the only thing I (we I believe) would have split out in an ideal world. Next on my list would be the processing and forwarding mechanism in OLSRv2 that is d…

In fact I moved both of them out of the OLSRv2 core code in my implementation.

Henning Rogge

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 11 Sep 2014 13:25:12 +0200

Agree with Chris and Henning here.

Sent from my iPad

> On 11 Sep 2014, at 12:02, Christopher Dearlove <[email-masked]> wrote:
>

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 11 Sep 2014 13:29:12 +0200

> On 11 Sep 2014, at 13:12, Christopher Dearlove <[email-masked]> wrote:
> 

In an ideal world, once we have about 10 years of operational experience with OLSRv2 (so, let's pick that up in 2024...)  if we push this onto the next level on the standards track, that would be the occasion to re-visit this. 

But, FWIW, the processing/forwarding engine from OLSRv2, and the MPR handling, both are sufficiently generic to be useful factored out (similar to NHDP and packetbb). There are a couple of other things from OLSRv2, that I think would fall into that category, but that is for another discussion another time, and perhaps in another venue.

Thomas

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 11 Sep 2014 13:29:32 +0200

> On 11 Sep 2014, at 13:15, Henning Rogge <[email-masked]> wrote:
> 

I think that we all did ;)

Thomas

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 11 Sep 2014 13:44:56 -0700

Hello Henning,

The intention is that AODVv2 should also be able to work using
MPRs for disseminating RREQ.  If there is anything in the specification
that would prohibit that, please let me know.

Regards,
Charlie P.

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 11 Sep 2014 13:57:31 -0700

Hello Henning,

> security practices" or whatever).

Seriously?  How would such a document be written so that sometimes
RFC 5444 would know to use this security practice (i.e., in the case of 
AODVv2)
and sometimes it would know not to do so?  Do we need to create a new
registry of [manet] protocols and have the security requirements of each
one tabulated for the benefit of RFC 5444?  This would be a new
feature potentially making earlier implementations noncompliant.

How about, in the meantime, if we create a new section in the AODVv2
document entitled "Recommended RFC 5444 security practices"?

> On implementation level? Just as you do now, just a line of code in

No problem, but presumably the implementation depends on the specification.

> all) AODVv2 implementations (some might implement other security

Some routing protocols might not need such a thing, or may
specify other mechanisms that effectively provide a security
superset.  However, I find the following to be confusing:

- routing protocol A needs security protections 'A', as specified
    by other IETF documents
- routing protocol B needs other security protections, not exactly
    the same as needed by A

Then, if one tries to live within the RFC 5444 constraints as
recently characterized,  I don't see how RFC 5444 can resolve
this without some instruction from the routing protocol.  This
would require new features.

Alternatively, we could say that RFC 5444 requires a whole new
set of security features tailored to the particular requirements
of message bundling and topology management.  Well, I guess
that would be great for some purposes, but I really think it is
the wrong approach.

Regards,
Charlie P.

PS.  There has been so much email on this topic that I might
         have overlooked something -- please send me a reminder
         in that case!

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 11 Sep 2014 22:06:10 +0100

Once again, this is not specific to AODVv2. Why is it in any way different to NHDP's requirements? How can one protocol be allowed to dictate to a multi-protocol process? Why is this always one step forward and two back on AODVv2 confirming to the WG agreed structure?

> On 11 Sep 2014, at 21:57, Charlie Perkins <[email-masked]> wrote:
> 
> 
> Hello Henning,
> 
> RFC 5444 would know to use this security practice (i.e., in the case of AODVv2)

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 11 Sep 2014 23:07:41 +0200

Again...having developed, implemented, and deployed reactive and proactive routing protocols that are trivially compliant with RFC5444, I do sincerely not understand what it is that causes the current authors of this particular protocol so much suffering. 

This email pulls out hypothetical arguments such as:

  "routing protocol A needs security protections 'A'.... routing protocol
     B needs other security protections, not exactly the same as needed by A"

Which, honestly, seems really like the current authors trying really hard to create a problem where none exists, to simply discredit past WG consensus.

Thomas

Sent from my iPad

> On 11 Sep 2014, at 22:57, Charlie Perkins <[email-masked]> wrote:
> 
> 
> Hello Henning,
>

---

From: Charlie Perkins <[email-masked]>
Date: Thu, 11 Sep 2014 14:15:35 -0700

Hello Chris,

I really think you are putting this in the wrong context.

To wit, it's not just AODVv2.  It's *all future protocols*.

Plus, I think I could easily make the argument that NHDP
*should* specify TTL=255.  But that is *not* my problem,
and I am not expecting to argue about it.

Furthermore, as noted previously, there is no place that
I noticed in RFC 5444 prohibiting routing protocols from
specifying TTL=255, and it remains mysterious to me why
a message bundling protocol would be specified in such
a way to have that effect.

But, and this is important, I am *not* trying to avoid
conformance to RFC 5444.  It's just that there have been
several times when behavior not explicitly specified within
the RFC 5444 document turns out to not conform to other
unstated assumptions that were made by the authors of
RFC 5444.

So I think your characterization:
                "always one step forward and two back on AODVv2"
is simply wrong, and not constructive.  If anything, I think
the discussion has been useful in terms of how well RFC 5444
serves the needs of protocol designers who are not faced with
the burden of compressing dozens or hundreds of addresses.

Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 11 Sep 2014 22:52:13 +0100

I could write something longer, but I'm just tired of making the same points (also independently made by at least two other people) especially when I'm supposed to be on holiday. Suffice to say, nothing you have just said either recognises the issues or changes the position.

> On 11 Sep 2014, at 22:15, Charlie Perkins <[email-masked]> wrote:
> 
> 
> Hello Chris,
>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 11 Sep 2014 22:43:56 +0000

> Which, honestly, seems really like the current authors trying really hard to create a problem where none exists, to simply discredit past WG consensus.

I respectfully disagree, and I take exception to the above characterization. 

>From my perspective, there was a question asked: "How would (or could) an RFC5444-compliant protocol take advantage of things like setting TTL=255 on a packet?" 
It would appear from this thread that the answer is "You don't." Or rather, "You can't." 

Got it. 

I now ask all involved - let's bring the temperature down a few notches, please. 

Stan

---

From: Thomas Clausen <[email-masked]>
Date: Fri, 12 Sep 2014 01:02:29 +0200

> On 12 Sep 2014, at 00:43, Stan Ratliff (sratliff) <[email-masked]> wrote:
> 
> 

Fair enough - I was responding to mr. Perkins and I wouldn't know if you or mr. Dowdell share his  perspective and opinion. I should not have painted all the current authors with the same brush. Please accept my apologies, to you and mr Dowdell.

That said, I maintain that the messages from mr. Perkins read as if "discredit past WG consensus" is the express intent since - as I indicated, I have experience designing, implementing, and deploying, both proactive and reactive rfc5444-compliant protocols without encountering grief and suffering such as is being expressed.

> I now ask all involved - let's bring the temperature down a few notches, please. 
I *think* you are quoting in a way such that it appears that you are replying to me in the above.. I think that I did  not write what you are quoting and responding to.

Respectfully,

Thomas

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 11 Sep 2014 23:09:57 +0000

> I *think* you are quoting in a way such that it appears that you are replying to me in the above.. I think that I did  not write what you are quoting and responding to.

Then my apologies are in order for what a colleague refers to as "communicating sloppily". In my last posting, the quotations were meant as my distillation of the email thread. I did not intend for it to be taken as quoting a specific person's response, and I apologize that I did not clarify that. 

Regards,
Stan

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 12 Sep 2014 02:33:18 +0200

I agree with Charlie,

AB