Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 7 Sep 2014 22:21:44 +0200

On Thursday, April 3, 2014, manet issue tracker wrote:

> #33: RFC 5444 processing constraint
>
>  (Thomas Clausen)
>  I have a general concern about how this protocol imposes constraints
>  on RFC5444 usage, which precludes co-existence with other RFC5444
>  protocols running on the same device.

You refer to which device (is it device with many routings) and still IETF
has no RFC specifying rules for handling other RFC5444 protocols
together running on same device. So that is future possible technology.

>  Let me give an example hereof, from Section 5.4:
>
>
>  {{{
>                  When multiple messages are aggregated into a single packet
>                  according to RFC 5444 formatting, and the aggregation of
>                  messages is also authenticated (e.g., with IPsec), and the
>                  IP destination is multiple hops away, it becomes
>  infeasible
>                  to delete individual messages.  In such cases, instead of
>                  deleting individual messages, they are maintained in the
>                  aggregation of messages, but simply ignored for further
>                  processing.  In such cases where individual messages
>  cannot
>                  be deleted, in this document "disregarded" means
>  "ignored".
>                  Otherwise, any such "disregarded" AODVv2 messages SHOULD
>  be
>                  deleted from the aggregated messages in the RFC 5444
>  packet.
>  }}}
>
>  An RFC5444 packet is *never* to be sent more than one hop.
>  ... A router receives an RFC5444 packet, decapsulates
>  it, process each message (if appropriate), the owner process of each
>  message identifies which messages are to be forwarded (if appropriate),
>  hands those off to the appropriate "message multiplexing engine" which
>  packs those messages up in a new RFC5444 packet, and transmits that
>  new RFC5444 packet.

There is no 5444 multiplexing methods specified in IETF.  However, I think
it is wrong designing protocols depending on formats, we design protocols
then our formats and our multiplexing depend on our protocols.

>  Also, in RFC5444 messages, addresses are contained in address blocks.
>  There is no semantics associated with an address being in one address
>  block, or in another (in fact, (re-)organising addresses into address
>  blocks is one of the tricks to use to obtain more compact messages).
>  Likewise, there is no semantics associated with an address being first,
>  last, or in any other position in an address block: the ordering of
>  addresses in an address block carries no semantics.

You base your definition on which RFC, I think each protocol defines its
own semantics as noticed by RFC5444.

>
>  Therefore, writing something like this:
>
>
>  {{{
>                  RteMsg.Address[i] denotes the [i]th address in an RFC 5444
>                  AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes the
>                  associated prefix length for RteMsg.Address[i], and
>                  RteMsg.{field} denotes the corresponding value in the
>  named
>                  AddrTLV block associated with RteMsg.Address[i].
>  }}}
>
>
>  makes no sense whatsoever (aside from the fact that I do not understand
>  the notation !RteMsg.{field} - that would indicate a "field" in a
>  message, not in an attribute associated with an address).
>
>  Let me give one more example, from section 9:
>
>
>  {{{
>             If a message with an unknown type is received, the message is
>             disregarded.
>  }}}
>
>
>  An implementation of this specification will (according to RFC5444)
>  "own", and therefore get messages that this protocol has gotten
>  assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK.  Messages of any
>  other Message Types will not (again, according to RFC5444) be
>  delivered to an implementation of this protocol.
>
>  Therefore, this protocol <should not>
>  specify discarding any message types other than those than it "owns".

Disregard does not mean drop, so those messages are still in
next 5444 packet. This comes back to multiplexing by ownership or not,
which that is not specified yet so we leave it for another future draft for
multiplexing. We need to focus this reactive standard not make it
complicated.

AB

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Sun, 7 Sep 2014 20:46:35 +0000

Abdussalam,

On Sep 7, 2014, at 4:21 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

 (Thomas Clausen)

You refer to which device (is it device with many routings) and still IETF has no RFC specifying rules for handling other RFC5444 protocols together running on same device. So that is future possible technology.

I do not understand what you wrote above. RFC5444 is specified as a "MUST" for all routing protocols *coming from the MANET WG*. As for other protocols (e.g. OSPF), there are no rules because there is no intersection.

 {{{

There is no 5444 multiplexing methods specified in IETF.  However, I think it is wrong designing protocols depending on formats, we design protocols then our formats and our multiplexing depend on our protocols.

RFC5444 itself describes ways that multiple (MANET WG-developed) protocols can be multiplexed.

You base your definition on which RFC, I think each protocol defines its own semantics as noticed by RFC5444.

I believe that to be incorrect - the notion is that:
(1)  RFC5444 is specified as a MUST for all MANET WG-developed routing protocols.
(2)  RFC5444 expresses no semantics with regard to ordering of address blocks in messages.
(3)  If the proposed protocol (in this case, AODVv2), imposes ordering of address blocks, then it (AODVv2) is incorrectly implementing RFC5444.

 {{{

 {{{

Disregard does not mean drop, so those messages are still in next 5444 packet. This comes back to multiplexing by ownership or not, which that is not specified yet so we leave it for another future draft for multiplexing. We need to focus this reactive standard not make it complicated.

Again, I respectfully disagree. A deployment model to envision is a router, running both OLSRv2 and AODVv2. Both of those protocols share a transport using RFC5444 to a second router, which is also running both protocols. The "multiplexing" being spoken of would be a mix of OLSRv2 and AODVv2 messages, bundled up into an RFC5444 packet.

Regards,
Stan

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

---

From: Christopher Dearlove <[email-masked]>
Date: Sun, 7 Sep 2014 21:55:21 +0100

As Stan has said, with one addition (unless Stan said it and I missed it). 5444 describes how messages can be multiplexed. 5498 says (as part of its using of the MANET protocol or port) you must use that multiplexing method. The WG has decided that means the protocols it is developing (with the obvious exception of DLEP that isn't a MANET routing protocol).

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

> On 7 Sep 2014, at 21:46, "Stan Ratliff (sratliff)" <[email-masked]> wrote:
> 
> Abdussalam, 
> 
>> On Sep 7, 2014, at 4:21 PM, Abdussalam Baryun <[email-masked]> wrote:
>> 
>> 
>> 
>> [email-masked]
> [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Mon, 8 Sep 2014 08:00:42 +0200

On Sun, Sep 7, 2014 at 10:55 PM, Christopher Dearlove
<[email-masked]> wrote:
> As Stan has said, with one addition (unless Stan said it and I missed it).
> 5444 describes how messages can be multiplexed. 5498 says (as part of its
> using of the MANET protocol or port) you must use that multiplexing method.
> The WG has decided that means the protocols it is developing (with the
> obvious exception of DLEP that isn't a MANET routing protocol).

There is also the point that the whole focus on a TLV based format
becomes mostly pointless when you put that much information into
non-tlv parts like element order that you loose too much flexibility
and extensibility.

One of the "lesson learned" from RFC3626 was that you should never
assume that you know what you need in a protocol. RFC3626 allowed a
add new messages to the protocol, but it didn't allow to add
information to existing messages. RFC5444 (as a packet format) tries
to solve this problem.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 9 Sep 2014 02:58:19 +0200

Hi Stan,

On Sunday, September 7, 2014, Stan Ratliff (sratliff) wrote:

>  You refer to which device (is it device with many routings) and still
> IETF has no RFC specifying rules for handling other RFC5444 protocols
>  I do not understand what you wrote above. RFC5444 is specified as a
> "MUST" for all routing protocols *coming from the MANET WG*. As for other
> protocols (e.g. OSPF), there are no rules because there is no intersection.
>

I mean As if we have hybrid manet how devices will multiplex 5444 packets.
We still are not looking into hybrid routing issues. Yes RFC5444 specifies
formats for MANET protocols, however, IMHO it states that each protocol
defines its own messages and packets in some format conditions (i.
e, RFC5444) but not specifies multiplexing methods of those general format.

>  There is no 5444 multiplexing methods specified in IETF.  However, I
> think it is wrong designing protocols depending on formats, we design
> protocols then our formats and our multiplexing depend on our protocols.
>
>

As optional not mandatory. RFC5444 seems independent to parser methods and
routing protocols. Yes if we require multiple protocols cooperation then
the parser needs to be specified for that job not the routing protocols.
RFC5444 states that parser is independent of protocols. For hybrid
routing protocol drafts we must specify parser.

> (1)  RFC5444 is specified as a MUST for all MANET WG-developed routing

This point is not against my input. I agree. So AODVv2 is using RFC5444 but
why we stick it to the parser. Chris input is explaining as packets are
only created at parsers but I think that RFC5444 does give option to
protocols to create packets as well. The process of only parsers do the job
of packing is not specified on RFC5444 nor in RFC5498.

> (2)  RFC5444 expresses no semantics with regard to ordering of address

I know that it only gives syntax and conditions. So this is not against my
input also. So each protocol can use 5444 with each having their own
semantic of their messages/information (and even their way of packing their
information).

(3)  If the proposed protocol (in this case, AODVv2), imposes ordering of
> address blocks, then it (AODVv2) is incorrectly implementing RFC5444.
>

Not sure why you think that way. RFC5444 is not against ordering inside
a block. IMHO You misunderstood the ordering, because it is inside the one
address-block. So I agree we don't have ordering of blocks in RFC5444 and
also AODVv2 draft does not say ordering blocks.

>  Again, I respectfully disagree. A deployment model to envision is a
> router, running both OLSRv2 and AODVv2. Both of those protocols share a
> transport using RFC5444 to a second router, which is also running both
> protocols. The "multiplexing" being spoken of would be a mix of OLSRv2 and
> AODVv2 messages, bundled up into an RFC5444 packet.
>

Ok, to be more general and to serve majority users of AODVv2 and more
security consideration.  we need to consider that some users don't want
such mix network and some do. First if users are wanting your mix scenario
then they go for a parser that is unified for both protocols ( this
case routers need same multiplexing method otherwise they don't work
), while parsers are independent of protocols as RFC5444 says. If the
AODVv2 sends a packet then parser is able to do packing again locally with
adding other messages if available. Secondly,  users don't want to use
specific unified parser dependence, so just the one protocol packing with
its user method for security purpose. This way we have more independence
for this AODVv2.

AB

---

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

On Sunday, September 7, 2014, Christopher Dearlove wrote:

> 5444 describes how messages can be multiplexed.
>

5444 describes syntax not semantics of packing information, it also does
not describe multiplexing as not owned by protocols. So you argue that
AODVv2 draft should not mention packets as if RFC5444 means that packets
are only for parsers.

> 5498 says (as part of its using of the MANET protocol or port) you must
> use that multiplexing method.
>

IMHO It says we must use that specified syntax of information. And if using
many routing protocols in same network yes you must use unified parser (to
reduce overheads).

The multiplexing needs to be unified when you want to mix routing protocols
but if you don't want that for security purposes then leave
unified multiplexing, just use the routing protocol and put your new secure
packing. Parser and multiplexing needs a separate draft because there are
many problems with it and many considerations.

AB

---

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

On Tue, Sep 9, 2014 at 3:15 AM, Abdussalam Baryun
<[email-masked]> wrote:
> And if using many routing protocols in same network yes you must use unified parser (to
> reduce overheads).

Every OLSRv2 implementation out there is doing this anyways because
they have to combine the OLSRv2 protocol with the NHDP protocol.

Every SMF implementation that use a reduced flooding set by using MPRs
is doing this too (hint, its because of a second protocol called
NHDP).

Oh, using AODVv2 with proactive neighbor detection might make this
"two protocols" necessary too.

And my "NHDP dualstack" draft suggests doing it with multiple protocol
instances, one for IPv4 and one for IPv4.

You notice a pattern?

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 9 Sep 2014 14:36:33 +0000

On Sep 8, 2014, at 8:58 PM, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> wrote:

Ok, to be more general and to serve majority users of AODVv2 and more security consideration.  we need to consider that some users don't want such mix network and some do. First if users are wanting your mix scenario then they go for a parser that is unified for both protocols ( this case routers need same multiplexing method otherwise they don't work ), while parsers are independent of protocols as RFC5444 says. If the AODVv2 sends a packet then parser is able to do packing again locally with adding other messages if available. Secondly,  users don't want to use specific unified parser dependence, so just the one protocol packing with its user method for security purpose. This way we have more independence for this AODVv2.

If a given protocol specification/design adheres to the RFC 5444 multiplexing as it should, then both of your scenarios above (e.g., "…some users don't want such mix network and some do.") work just fine. However, if a given protocol specification does NOT adhere to the RFC 5444 multiplexing, it then PRECLUDES the protocol from being used in what you are calling a "mixed network". In summary, adherence to the RFC 5444 multiplexing gives deployments MORE flexibility instead of less, and is, IMHO, the superior design choice.  As for your assertion that "…users don't want to use specific unified parser dependence…", I believe that is at best merely anecdotal, and at worst, completely baseless.

Regards,
Stan