Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-08
Charlie Perkins <charles.perkins@earthlink.net> Thu, 01 October 2020 17:26 UTC
Return-Path: <charles.perkins@earthlink.net>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A333A1171; Thu, 1 Oct 2020 10:26:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Level:
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsR865uPnEIx; Thu, 1 Oct 2020 10:25:58 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEFB3A1170; Thu, 1 Oct 2020 10:25:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1601573158; bh=HWycVSpQvBbbQqAAJ0mQdO26A9DK0cMTzGJW 2ia1TAM=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language: X-ELNK-Trace:X-Originating-IP; b=eska3frLvunhm/5pVvqOJU+kRELZhdqYT C5YEsKw31amyZNuvRS7QVp7188shgaf8gPDpCRQ95v0ICgo3WoF6mSawFAwghrPP2SV HTYvrFDtTFUVPbc3H+jlYqw3KwK8rOa4+M+w1SN0HYensxJT4tmvvRzyD7K59brgpne b2LtkJZPIW8d/MZsxWxMT9iwxh/h/Tc7+NH7anar/1LAvLzeQi9s1UVBuBDMS5uIoi6 CuqTTrmLkYqw0+N6aDZ2nMtieK3vi0ftgp1o64jYp/YD4BC2JdjCc9jH1AYi03boTbZ w0BSjpWioy6FsAHAddpPTg/7s9F0H/N0gUeoRBbfg==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=jdiTnQdA/i/9Mdeq1JwjluQcs5CkP/iFX7N1aoDNgS4BEP5gFo42f6ANay4mXev+HSXOKKyTuza9w/KGnFTUCINLMDl+2wNC4fDYrvPP6fNdie0+eDilQmrRm3wlq7dpStOYPxVyKaNB1xBllLWye7Y1onznvRNeF+KVVxcS/vmlYCIWbA1Vb7AGe5JoRqwlbaU4+91zpz1JSQIuRTxkGc5m8t6+nOdFHXIN5FVGSYCNLE18XX+ml03cKXevldCke5ONuYpJ2U/g88FpHqjcMW1PRP4M8/WhYjQvc7uoAKp7eSKT0anizaxDFGtHkoMShgQ29q6cliacga8pgg9REw==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charles.perkins@earthlink.net>) id 1kO2L7-00045I-0Q; Thu, 01 Oct 2020 13:25:57 -0400
To: Routing Over Low power and Lossy networks <roll@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-roll-aodv-rpl@ietf.org" <draft-ietf-roll-aodv-rpl@ietf.org>
Cc: roll-chairs@ietf.org, Ines Robles <mariainesrobles@googlemail.com>
References: <CAMMESsy+krNStGn7fA3pZ5xEwUSwiYDDjnSx2hhH1ZC8_Jd13A@mail.gmail.com> <CAMMESsxWHg422GTJOfDJtTHpV5X3U-0+4_nkuhRVM0GuC06fzg@mail.gmail.com>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <c93498f5-8aa8-0e27-51b1-0ce5d016627e@earthlink.net>
Date: Thu, 01 Oct 2020 10:25:54 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CAMMESsxWHg422GTJOfDJtTHpV5X3U-0+4_nkuhRVM0GuC06fzg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------6FD9F7E22D3124CA15B824EF"
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956df8303b86ceddf55492fc17ee048b72eb0b36bff673697d4350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/i7SLpXjKk3NvxVC5cU83ses4GGY>
Subject: Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-08
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Oct 2020 17:26:02 -0000
Hello folks, It's a busy time in this neck of the woods, due to end-of-month business deadlines. I'll try to respond next week. Regards, Charlie P. On 10/1/2020 9:15 AM, Alvaro Retana wrote: > Ping! > > On June 16, 2020 at 5:36:50 PM, Alvaro Retana (aretana.ietf@gmail.com > <mailto:aretana.ietf@gmail.com>) wrote: > >> >> Dear authors: >> >> This is an incremental review based on some of the changes and the >> new text in this version. Some of the comments are a followup to >> previous comments, but there are also some new issues. >> >> >> Thanks! >> >> Alvaro. >> >> >> [Line numbers from idnits.] >> >> ... >> 102 1. Introduction >> ... >> 125 AODV-RPL reuses and provides a natural extension to the core RPL >> 126 functionality to support routes with birectional asymmetric links. >> 127 It retains RPL's DODAG formation, RPL Instance and the associated >> 128 Objective Function, trickle timers, and support for storing and >> non- >> 129 storing modes. AODV adds basic messages RREQ and RREP as part >> of RPL >> 130 DIO (DODAG Information Object) control messages, and does not >> utilize >> 131 the DAO message of RPL. AODV-RPL specifies a new MOP running in a >> 132 seperate instance dedicating to discover P2P routes, which may >> differ >> 133 from the P2MP routes discoverable by native RPL. AODV-RPL can be >> 134 operated whether or not native RPL is running otherwise. >> >> [nit] s/seperate instance dedicating/separate instance dedicated >> >> [major] "AODV-RPL can be operated whether or not native RPL is >> running otherwise." If native RPL is also running in the LLN, it can >> learn the same routes as the ones discovered through AODV-RPL. Which >> route should have preference, or is this a deployment issue and >> outside the scope? >> >> [major] If native RPL is already running in an LLN, how would >> AODV-RPL be introduced in the network? I'm thinking about §2/rfc5706. >> >> >> 136 2. Terminology >> ... >> 144 AODV >> 145 Ad Hoc On-demand Distance Vector Routing[RFC3561]. >> >> [nit] s/Routing[RFC3561]/Routing [RFC3561] >> >> >> ... >> 422 4.3. AODV-RPL Target Option >> ... >> 451 Figure 3: Target option format for AODV-RPL MOP >> >> [minor] s/Target option/ART Option (or AODV-RPL Target option)/g(almost) >> >> There are some places where "target option" is used to refer to the >> ART option, but without the extra qualification it may be confused >> with the Target option in core RPL. IOW, let's be painfully specific. >> >> >> >> ... >> 485 5. Symmetric and Asymmetric Routes >> ... >> 539 Appendix A describes an example method using the ETX and RSSI to >> 540 estimate whether the link is symmetric in terms of link quality is >> 541 given in using an averaging technique. >> >> [minor] Please expand ETX/RSSI. >> >> >> ... >> 605 6.2.1. General Processing >> ... >> 615 If the S bit in the received RREQ-DIO is set to 1, the >> router MUST >> 616 determine whether each direction of the link (by which the >> RREQ- >> 617 DIO is received) satisfies the Objective Function. In case >> that >> 618 the downward (i.e. towards the TargNode) direction of the link >> 619 does not satisfy the Objective Function, the link can't be used >> 620 symmetrically, thus the S bit of the RREQ-DIO to be sent out >> MUST >> 621 be set as 0. If the S bit in the received RREQ-DIO is set >> to 0, >> 622 the router MUST only check into the upward direction >> (towards the >> 623 OrigNode) of the link. >> >> [major] s/MUST only check/MUST determine... >> >> You fixed the first occurrence of MUST check, but not the second. >> >> >> 625 If the upward direction of the link can satisfy the Objective >> 626 Function (defined in [RFC6551]), and the router's Rank would >> not >> 627 exceed the MaxUseRank limit, the router joins the DODAG of the >> 628 RREQ-Instance. The router that transmitted the received >> RREQ-DIO >> 629 is selected as the preferred parent. Otherwise, if the >> Objective >> 630 Function is not satisfied or the MaxUseRank limit is >> exceeded, the >> 631 router MUST discard the received RREQ-DIO and MUST NOT join the >> 632 DODAG. >> >> [minor] "Objective Function (defined in [RFC6551])" Put the >> reference when OF is first used. >> >> >> ... >> 642 If the H bit is set to 1, then the router (TargNode or >> 643 intermediate) MUST build an upward route entry towards OrigNode >> 644 which MUST include at least the following items: Source >> Address, >> 645 InstanceID, Destination Address, Next Hop, Lifetime, and >> Sequence >> 646 Number. The Destination Address and the InstanceID >> respectively >> 647 can be learned from the DODAGID and the RPLInstanceID of the >> RREQ- >> 648 DIO, and the Source Address is the address used by the local >> 649 router to send data to the OrigNode. The Next Hop is the >> 650 preferred parent. The lifetime is set according to DODAG >> 651 configuration (i.e., not the L bit) and can be extended when >> the >> 652 route is actually used. The sequence number represents the >> 653 freshness of the route entry, and it is copied from the Orig >> SeqNo >> 654 field of the RREQ option. A route entry with the same >> source and >> 655 destination address, same InstanceID, but stale sequence >> number, >> 656 MUST be deleted. >> >> [major] s/MUST build an upward route entry towards OrigNode which >> MUST include at least the following items/MUST build an upward route >> entry towards OrigNode which includes at least the following items >> >> >> 658 Step 4: >> >> 660 If the router is an intermediate router, then it transmits a >> RREQ- >> 661 DIO via link-local multicast; if the H bit is set to 0, the >> 662 intermediate router MUST include the address of the interface >> 663 receiving the RREQ-DIO into the address vector.. Otherwise, if >> 664 the router (i.e., TargNode) was not already associated with the >> 665 RREQ-Instance, it prepares a RREP-DIO Section 6.3. If, on the >> 666 other hand TargNode was already associated with the >> RREQ-Instance, >> 667 it takes no further action and does not send an RREP-DIO. >> >> [nit] s/../. >> >> [nit] s/Section 6.3./(Section 6.3). >> >> >> ... >> 764 6.4. Receiving and Forwarding Route Reply >> ... >> 773 If the S bit of the RREP-DIO is set to 0, the router MUST check >> 774 the downward direction of the link (towards the TargNode) over >> 775 which the RREP-DIO is received. If the downward direction >> of the >> 776 link can satisfy the Objective Function, and the router's Rank >> 777 would not exceed the MaxRank limit, the router joins the >> DODAG of >> 778 the RREP-Instance. The router that transmitted the received >> RREP- >> 779 DIO is selected as the preferred parent. Afterwards, other >> RREP- >> 780 DIO messages can be received. >> >> [] s/the router MUST check.../the router MUST determine...satisfies >> >> IOW, join the two sentences. >> >> >> ... >> 794 If the H bit is set to 1, then the router (OrigNode or >> 795 intermediate) MUST build a downward route entry. The route >> entry >> 796 MUST include at least the following items: OrigNode Address, >> 797 InstanceID, TargNode Address as destination, Next Hop, Lifetime >> 798 and Sequence Number. For a symmetric route, the Next Hop in >> the >> 799 route entry is the router from which the RREP-DIO is received. >> 800 For an asymmetric route, the Next Hop is the preferred >> parent in >> 801 the DODAG of RREQ-Instance. The InstanceID in the route entry >> 802 MUST be the original RPLInstanceID (after subtracting the Shift >> 803 field value). The source address is learned from the ART >> Option, >> 804 and the destination address is learned from the DODAGID. The >> 805 lifetime is set according to DODAG configuration and can be >> 806 extended when the route is actually used. The sequence number >> 807 represents the freshness of the route entry, and is copied from >> 808 the Dest SeqNo field of the ART option of the RREP-DIO. A >> route >> 809 entry with same source and destination address, same >> InstanceID, >> 810 but stale sequence number, SHOULD be deleted. >> >> [major] s/MUST build a downward route entry. The route entry MUST >> include at least the following items/MUST build a downward route >> entry towards TargNode which includes at least the following items >> >> [minor] s/The lifetime is set according to DODAG configuration and >> can be extended when the route is actually used./The lifetime is set >> according to DODAG configuration (i.e., not the L bit) and can be >> extended when the route is actually used. >> >> [major] s/stale sequence number, SHOULD be deleted./stale sequence >> number, MUST be deleted. >> >> >> 812 If the H bit is set to 0, for an asymmetric route, an >> intermediate >> 813 router MUST include the address of the interface receiving the >> 814 RREP-DIO into the address vector; for a symmetric route, >> there is >> 815 nothing to do in this step. >> >> [minor] In §6.2.1 the part about H=0 was moved to Step 4. Please do >> the same here. >> >> >> ... >> 830 Upon receiving a RREP-DIO, a router which already belongs to the >> 831 RREQ-Instance SHOULD drop the RREP-DIO. >> >> [minor] When it is ok to not drop it? I'm assuming that there's no >> harm in propagating the extra RREP, right? IOW, there's no need for >> MUST. >> >> >> >> ... >> 876 9.1. New Mode of Operation: AODV-RPL >> >> 878 IANA is asked to assign a new Mode of Operation, named >> "AODV-RPL" for >> 879 Point-to-Point(P2P) hop-by-hop routing from the "Mode of >> Operation" >> 880 Registry [RFC6550]. >> >> [major] The reference is not needed because even though the registry >> was defined in rfc6550, the RFC is not the registry. >> >> [major] A note should be added indicating that the number in >> parenthesis is a suggestion. >> >> >> 882 +-------------+---------------+---------------+ >> 883 | Value | Description | Reference | >> 884 +-------------+---------------+---------------+ >> 885 | TBD1 (5) | AODV-RPL | This document | >> 886 +-------------+---------------+---------------+ >> >> 888 Figure 6: Mode of Operation >> >> 890 9.2. AODV-RPL Options: RREQ, RREP, and Target >> >> 892 IANA is asked to assign three new AODV-RPL options "RREQ", >> "RREP" and >> 893 "ART", as described in Figure 7 from the "RPL Control Message >> 894 Options" Registry [RFC6550]. >> >> [major] The reference is not needed because even though the registry >> was defined in rfc6550, the RFC is not the registry. >> >> [major] A note should be added indicating that the number in >> parenthesis is a suggestion. >> >> >> 896 +-------------+------------------------+---------------+ >> 897 | Value | Meaning | Reference | >> 898 +-------------+------------------------+---------------+ >> 899 | TBD2 (0x0A) | RREQ Option | This document | >> 900 +-------------+------------------------+---------------+ >> 901 | TBD3 (0x0B) | RREP Option | This document | >> 902 +-------------+------------------------+---------------+ >> 903 | TBD4 (0x0C) | ART Option | This document | >> 904 +-------------+------------------------+---------------+ >> >> [major] 0x0a is already assigned to rfc6997! >> >> >> 906 Figure 7: AODV-RPL Options >> >> 908 10. Security Considerations >> >> 910 In general, the security considerations for the operation of >> AODV-RPL >> 911 are similar to those for the operation of RPL (as described in >> 912 Section 19 of the RPL specification [RFC6550]). Sections 6.1 >> and 10 >> 913 of [RFC6550] describe RPL's security framework, which provides >> data >> 914 confidentiality, authentication, replay protection, and delay >> 915 protection services. >> >> [] It may be a god idea to also point at rfc7416 as an Informative >> reference. >> >> >> ... >> 924 If a rogue router knows the key for the Security Configuration in >> 925 use, it can join the secure AODV-RPL route discovery and cause >> 926 various types of damage. Such a rogue router could advertise >> false >> 927 information in its DIOs in order to include itself in the >> discovered >> 928 route(s). It could generate bogus RREQ-DIO, and RREP-DIO messages >> 929 carrying bad routes or maliciously modify genuine RREP-DIO >> messages >> 930 it receives. A rogue router acting as the OrigNode could launch >> 931 denial-of-service attacks against the LLN deployment by initiating >> 932 fake AODV-RPL route discoveries. In this type of scenario, RPL's >> 933 authenticated mode of operation, where a node can obtain the >> key to >> 934 use for a P2P-RPL route discovery only after proper >> authentication, >> 935 SHOULD be used. >> >> [major] rfc6550 says this: >> >> Authenticated mode cannot be supported by symmetric algorithms. As >> of the >> writing of this specification, RPL supports only symmetric >> algorithms: >> authenticated mode is included for the benefit of potential future >> cryptographic primitives. >> >> If I'm interpreting this correctly, there is really no authentication >> defined for RPL that can apply here. Has something been defined >> after that? IOW, what "SHOULD be used"? >> >> >> 937 When RREQ-DIO message uses source routing option with 'H' set >> to 0, >> 938 some of the security concerns that led to the deprecation of >> Type 0 >> 939 routing headers [RFC5095] may apply. To avoid the possibility >> of a >> 940 RREP-DIO message traveling in a routing loop, if one of its >> addresses >> 941 are present as part of the Source Route listed inside the message, >> 942 the Intermediate Router MUST NOT forward the message. >> >> [major] rfc5095 will probably raise a lot of flags... >> >> Suggestion> >> When a RREQ-DIO message uses the source routing option by setting >> the H >> bit to 0, a rogue router may populate the Address Vector field >> with a set >> of addresses that may result in the RREP-DIO traveling in a >> routing loop. >> The TargNode MUST NOT generate a RREP if one of its addresses is >> present >> in the Address Vector. An Intermediate Router MUST NOT forward a >> RREP if >> one of its addresses is present in the Address Vector. >> >> >> >> 944 11. Link State Determination >> >> [major] There's already text in §5 that pretty much says the same >> thing...except for the first sentence; I couldn't find a place where >> it says that symmetric is the default, did I miss it? >> >> In any case, I think that because of the text in §5, this section is >> not needed. >> >> 946 This document specifies that links are considered symmetric until >> 947 additional information is collected. Other link metric >> information >> 948 can be acquired before AODV-RPL operation, by executing evaluation >> 949 procedures; for instance test traffic can be generated between >> nodes >> 950 of the deployed network. During AODV-RPL operation, OAM >> techniques >> 951 for evaluating link state (see([RFC7548], [RFC7276], [co-ioam]) >> MAY >> 952 be used (at regular intervals appropriate for the LLN). The >> 953 evaluation procedures are out of scope for AODV-RPL. >> >> >> 955 12. References >> >> 957 12.1. Normative References >> ... >> 964 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- >> 965 Demand Distance Vector (AODV) Routing", RFC 3561, >> 966 DOI 10.17487/RFC3561, July 2003, >> 967 <https://www.rfc-editor.org/info/rfc3561>. >> >> [major] This doesn't have to be a Normative reference. >> >> >> ... >> 991 [RFC6998] Goyal, M., Ed., Baccelli, E., Brandt, A., and J. >> Martocci, >> 992 "A Mechanism to Measure the Routing Metrics along a >> Point- >> 993 to-Point Route in a Low-Power and Lossy Network", >> 994 RFC 6998, DOI 10.17487/RFC6998, August 2013, >> 995 <https://www.rfc-editor.org/info/rfc6998>. >> >> [major] This shouldn't be a Normative reference. >> >> Please make both of them Informative to avoid the DownRef. >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
- [Roll] AD Review of draft-ietf-roll-aodv-rpl-08 Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-… Alvaro Retana
- Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-… Charlie Perkins
- Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-… Charlie Perkins
- Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-… Alvaro Retana