Subject: [manet] Fwd: QA Review - Routing directorate review of draft-ietf-manet-aodvv2

From: Stan Ratliff <[email-masked]>
Date: Tue, 11 Aug 2015 11:28:04 -0400

---------- Forwarded message ----------
From: Keyur Patel (keyupate) <[email-masked]>
Date: Mon, Jun 22, 2015 at 10:05 PM
Subject: QA Review - Routing directorate review of draft-ietf-manet-aodvv2
To: Jonathan Hardwick <[email-masked]>, "
[email-masked]" <[email-masked]>, "[email-masked]" <
[email-masked]>
Cc: "[email-masked]" <[email-masked]>

Hi Jonathan,

I couldn’t get hold of an official format for a QA review. I have tried to
reuse the standard Rtg-dir template.

IMHO, There are two drafts here. There is a draft for AODVv2 and there is a
protocol applicability draft.  The authors should consider breaking the
draft into two separate drafts. Furthermore, this draft can definitely
benefit from some state-machine diagrams to explain protocol operations.

Otherwise the draft is written well considering its size. :)

Regards,

Keyur

Document: draft-ietf-manet-aodvv2-09
Reviewer: Keyur Patel
Review Date: 22-June-2015
Intended Status: Standards Track

Summary:
No major issues found. 2 Minor issues identified. Minor nits are listed
below.

Comments:
IMHO, the document is well written and easily understood.

Major Issues:
None.

Minor Issues:

1 Section 6.5.1 comparison 3:

What happens if the old and new route has a different metric type (default
versus other metric type). What is the tie breaking mechanism? Can we add
some text to clarify it?

2 Section 6.5.1 comparison 3: point 2, if AdvRte is better, shouldnt it be
checked to

    validate if its safe against routing loops?

3 Security Section: Security section is a bit weak. Since the packets are
rate-limited, the DDOS can become a significant factor. If Encrpytion is
suggested, then authors should clearly explain 1) How would it be used, 2)
How does one go about avoiding DDOS of bogus encryption packets.

Nits:

1) Section 1, 2nd para:

<snip>

AODVv2 routers use Route Reply and Route Request messages to carry route
information between the originator of the route discovery and the target...

<snip>

Replace with : AODVv2 routers use Route Request (RREQ) and Route Reply
(RREP) messages to carry route information between the originator of the
route discovery and the target, …

2) Section 1. What exactly is a target? Can we have Terminology section
cover definition of a target?

3) Section 1, 3rd paragraph

Replace with: Metric is included in RREQ and RREP message to represent the
cost of the route….

4) Applicability Statement – IMHO, This should be a separate draft
(applicability draft for AODV2).

5)   Data Structures - section a bit too implementation specifc. The
conceptual Route Table entry stucture is an implementation specific DS.

6) Section 5.2

<snip>

advertised route to update the route table will not cause a routing loop to
form.

</snip>

Replace with: advertised route does not create any routing loops.

7) Section 5.3 Default Metric type 3rd paragraph.

<snip>

The LoopFree function is derived from the fact that route cost...

</snip>

This paragraph should be moved to secion 5.2 where the loop free function
is described.

8) Section 5.4 4th paragraph

<snip>

Further, any strictly increasing metric can be supported using the LoopFree

</snip>

replace with: Furthermore, any strictly increasing metric can be supported
using the LoopFree

9) It is worth considering moving section 6: Protocol operations ahead of
section 5 Metric section (Swap them).

10) Section 6.3

<snip>

o avoid congestion, each AODVv2 router's rate of message generation

   (CONTROL_TRAFFIC_LIMIT) SHOULD be limited and administratively

   configurable.  The implementation is free to choose the algorithm for

   limiting messages, including prioritizing messages when approaching

   the limit.  AODVv2 messages SHOULD be discarded in the following

   order: RERR for invalidated routes, RREQ, RREP, RERR for

   undeliverable packet, RREP_Ack.

</snip>

It would be nice to move the definition of an invalidated route before
referencing it in this section.

11) Section 6.4: 4th para:

<snip>

Determining which packets

   to discard first when the buffer is full is a matter of policy at

   each AODVv2 router; in the absence of policy constraints, older data

   packets SHOULD be discarded first.

</snip>

Possible to take the suggestion out and leave it for implementations to
decide?

12)  Section 6.5.2: It would be nice for Section 6.5.2 to cover under what
circumstances Route.State moves to confirm/Active. Note that the first
paragraph does make a passing reference of the state change and section
6.7.1 explains the states. Section 6.5.2 seems to be missing an event
(description) in a state machine (explained in section 6.5.2)

13) Section 6.7.2: Can we add a case that describes if the looked up route
itself is invalid one (aside from an active route becoming invalid)?

14) Section 7.1, 7.2, and 7.4 should cover size for all data elements
described along with their descriptions.

15)   Section 7.4.1: Isnt it harmful to rate limit RERR messages (route
withdrawals)?

16)  Section 9 should be moved out to a separate applicability draft. Some
of the sections in Appendix could also be moved out to an applicability
draft.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 11 Aug 2015 15:36:17 +0000

Was this posted on the MANET list? If so, I missed it. Which list(s) was it posted on, and I should also be subscribed to?

I have to say for a review that far back, it missed quite a lot it should have been commenting on.

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

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 Stan Ratliff
Sent: 11 August 2015 16:28
To: MANET IETF
Subject: [manet] Fwd: QA Review - Routing directorate review of draft-ietf-manet-aodvv2

*** 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 ***
This message originates from outside our organization, either from an external partner or the internet. Consider carefully whether you should click on any links, open any attachments or reply. For additional information about Spearphishing, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Pages/SpearphishingTips.aspx>. 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>

---------- Forwarded message ----------
From: Keyur Patel (keyupate) <[email-masked]<mailto:[email-masked]>>
Date: Mon, Jun 22, 2015 at 10:05 PM
Subject: QA Review - Routing directorate review of draft-ietf-manet-aodvv2
To: Jonathan Hardwick <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Jonathan,

I couldn’t get hold of an official format for a QA review. I have tried to reuse the standard Rtg-dir template.

IMHO, There are two drafts here. There is a draft for AODVv2 and there is a protocol applicability draft.  The authors should consider breaking the draft into two separate drafts. Furthermore, this draft can definitely benefit from some state-machine diagrams to explain protocol operations.

Regards,

Keyur

Summary:
No major issues found. 2 Minor issues identified. Minor nits are listed below.

Comments:

Major Issues:
None.

Minor Issues:

What happens if the old and new route has a different metric type (default versus other metric type). What is the tie breaking mechanism? Can we add some text to clarify it?

2 Section 6.5.1 comparison 3: point 2, if AdvRte is better, shouldnt it be checked to

3 Security Section: Security section is a bit weak. Since the packets are rate-limited, the DDOS can become a significant factor. If Encrpytion is suggested, then authors should clearly explain 1) How would it be used, 2) How does one go about avoiding DDOS of bogus encryption packets.

Nits:

1) Section 1, 2nd para:

<snip>

AODVv2 routers use Route Reply and Route Request messages to carry route information between the originator of the route discovery and the target...

<snip>

Replace with : AODVv2 routers use Route Request (RREQ) and Route Reply (RREP) messages to carry route information between the originator of the route discovery and the target, …

2) Section 1. What exactly is a target? Can we have Terminology section cover definition of a target?

Replace with: Metric is included in RREQ and RREP message to represent the cost of the route….

4) Applicability Statement – IMHO, This should be a separate draft (applicability draft for AODV2).

5)   Data Structures - section a bit too implementation specifc. The conceptual Route Table entry stucture is an implementation specific DS.

6) Section 5.2

<snip>

advertised route to update the route table will not cause a routing loop to form.

</snip>

<snip>

</snip>

This paragraph should be moved to secion 5.2 where the loop free function is described.

<snip>

</snip>

replace with: Furthermore, any strictly increasing metric can be supported using the LoopFree

9) It is worth considering moving section 6: Protocol operations ahead of section 5 Metric section (Swap them).

10) Section 6.3

<snip>

</snip>

It would be nice to move the definition of an invalidated route before referencing it in this section.

<snip>

</snip>

Possible to take the suggestion out and leave it for implementations to decide?

12)  Section 6.5.2: It would be nice for Section 6.5.2 to cover under what circumstances Route.State moves to confirm/Active. Note that the first paragraph does make a passing reference of the state change and section 6.7.1 explains the states. Section 6.5.2 seems to be missing an event (description) in a state machine (explained in section 6.5.2)

13) Section 6.7.2: Can we add a case that describes if the looked up route itself is invalid one (aside from an active route becoming invalid)?

14) Section 7.1, 7.2, and 7.4 should cover size for all data elements described along with their descriptions.

15)   Section 7.4.1: Isnt it harmful to rate limit RERR messages (route withdrawals)?

16)  Section 9 should be moved out to a separate applicability draft. Some of the sections in Appendix could also be moved out to an applicability draft.

********************************************************************
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: Stan Ratliff <[email-masked]>
Date: Tue, 11 Aug 2015 11:47:42 -0400

Chris,

>From the email headers, it was unicasted.
As for your commentary on the review itself.... We asked for the review per
IETF procedure, this is the feedback we received. I am grateful that Keyur
took the time to review the document and provide comment.

Regards,
Stan

On Tue, Aug 11, 2015 at 11:36 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Was this posted on the MANET list? If so, I missed it. Which list(s) was
> it posted on, and I should also be subscribed to?
>
>
>
> *-- *
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> *From:* manet [mailto:[email-masked]] *On Behalf Of *Stan Ratliff
> *Sent:* 11 August 2015 16:28
> *To:* MANET IETF
> *Subject:* [manet] Fwd: QA Review - Routing directorate review of
> draft-ietf-manet-aodvv2
>
>
>
>
>
> **** 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 ****
> *This message originates from outside our organization, either from an
> external partner or the internet. Consider carefully whether you should
> click on any links, open any attachments or reply. For additional
> information about Spearphishing, click here
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Pages/SpearphishingTips.aspx>.
> 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>*
>
>
>
>
>
> From: *Keyur Patel (keyupate)* <[email-masked]>
> IMHO, There are two drafts here. There is a draft for AODVv2 and there is
> a protocol applicability draft.  The authors should consider breaking the
> 12)  Section 6.5.2: It would be nice for Section 6.5.2 to cover under
> what circumstances Route.State moves to confirm/Active. Note that the first
> 16)  Section 9 should be moved out to a separate applicability draft.
> Some of the sections in Appendix could also be moved out to an
> applicability draft.
>
>
>
>
>